-
Notifications
You must be signed in to change notification settings - Fork 725
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explicitly require the commands to help JS bundlers find all the code #962
Comments
Even if we did as you've suggested, bundlers probably would not recognize If your bundlers are ignoring the npm-supported ways of expressing which files are necessary, then these bundlers are likely to break the npm ecosystem. If these bundlers support APIs to tell them which files are necessary, I'm happy to take a look if these make sense to call in ShellJS, or in dependent modules. |
You are right. It seems that webpack manages to bundle the commands, but not the I used the following configuration in
and with the following source code in
and running the output file in a directory without the
|
Is there an API to tell webpack to keep this file? |
Hmm, not sure if there is a generic way to do it through Webpack has a few tricks around this but they are specific to it. I will need to play around a bit more and try a few things this week to see if I can get something working, and then we can see if it's something that can be merged into the main package. |
I just realized that Since I am not too familiar with Node's Might be a very stupid question but you probably already went through most of Node's API on this so might worth a shot asking anyway;p Thanks though in any way. |
The path forward would be to deprecate and later remove If bundler-users are OK with missing out on real-time stdio (instead, you would get stdout/stderr only as a pair of javascript strings) then this is probably fine. |
How about pre generate imports when build like this vercel/ncc#476 (comment) still keep the commands file, but help bundler |
ShellJS expects our own files will be present at runtime. If your bundler does not meet this expectation, we consider this a bug of the bundler. We will not generate require statements for the sake of tricking bundlers into keeping our files, especially in the case of Your bundler should examine our
I'm not sure what you mean. Are you proposing changes to ShellJS or to the bundler? |
@nfischer for pre generate I mean something like
scripts/generate-command-imports.js import commands.js write real imports to the file But you think the bundler should handle this, this tricks can also used as a workaround by those who use the bundler that can not handle this. |
The purpose of rollup etc, is to package the sources into a distribution. So, the design choice of requiring files to be present makes shelljs incompatible with bundlers. I was trying to use shelljs in a cli and wanted to use rollup in order to simplify the distribution. Is there a major downside to using explicit requires? |
Hey @nfischer, can you please help with this? |
…g issue (#539) ### Background This is a follow-up pr to fix the issue in #522. [Mark shelljs as external for esbuild bundling](#537) attempted to address this issue, but was not a successful solution for all of our tasks, as some of our tasks need the commands present in ShellJS. ### Problem This issue emerged with the bump of `azure-pipelines-task-lib` dependency in: #473. Problem detailed in the open issue on `azure-pipelines-task-lib` repo: [Cannot use JS bundler because of shelljs dependency](microsoft/azure-pipelines-task-lib#942). Essentially, the toolkit takes a dependency on `azure-pipelines-task-lib` which takes an additional dependency on ShellJS. Our toolkit uses the esbuild JS Bundler to build the extension. This fails to bundle ShellJS because it uses dynamic require statements ([problematic ShellJS code](https://github.com/shelljs/shelljs/blob/a6d1e49f180a495d83bcf67bd85782c626aae029/shell.js#L23-L26)) instead of explicit require statements, which prevents bundlers from correctly analyzing the dependencies. - In short, require('./a') works but require('./' + 'a') doesn't. [ShellJS has no plans to accommodate these explicit requires statements](shelljs/shelljs#962 (comment)) ### Solution Before making any larger scale changes, let's get `azure-pipelines-task-lib` back to its last known healthy state (working version we used for last release). This PR addresses that. ### Future `azure-pipelines-task-lib` updates Whenever we next bump the `azure-pipelines-task-lib` major version, we'll need to keep an eye on updates to microsoft/azure-pipelines-task-lib#942 for any new fixes or workarounds. Current known workarounds involve forking the ShellJS repository, making the necessary changes to ShellJS, and overriding the ShellJS dependency in `package.json` with the forked version. - [Example of forked ShellJS with hardcoded explicit `requires` statements](Everspace/shelljs@4e2ea23) - [Example of creating a bundler plugin with a fixed ShellJS file at compile time](https://github.com/tjosepo/azure-pipelines/blob/main/packages/esbuild-plugin-azure-pipelines-task-lib-fix/src/index.js)
For anyone affected, I've opened a new issue suggesting a fix for |
Node version (or tell us if you're using electron or some other framework):
v12.8.1
ShellJS version (the most recent version/Github branch you see the bug on):
0.8.3
Operating system:
Ubuntu 18.04.3 LTS
Description of the bug:
First of all, thanks for an amazing library, it has been working great for me in all cases I needed it. Apart from today that I tried bundling one of my Node apps.
It would be great if the calls to
requires
were explicit and not dynamic as it's done atshelljs/shell.js
Lines 24 to 26 in 57df38c
Reason is that when we want to bundle the whole Node application/script into a single JS file, it's impossible to get it to bundle correctly.
One example is something I was trying to do today using Shadow-CLJS; more details at thheller/shadow-cljs#290 (comment)
I tried almost every popular bundler, including
@zeit/ncc
,Parcel-bundler
,Rollup
, and finallyWebpack
.To be honest, I believe
webpack
managed to resolve the dynamicrequires
but then had other issues with__dirname
which I use in my code (whole other different issue).However, it would be much easier to integrate with these bundlers if the
requires
calls were explicit. Any specific reason why you go through the indirection ofarray of strings
and a loop to require versus the direct require of the commands (other than saving a few characters)?Thanks
The text was updated successfully, but these errors were encountered: