002 - Would appreciate more detail on the "asset pipeline" description

[wycats]

In 002:

Build asset pipelines in particular would be affected such as the Rails asset pipeline

Can you elaborate what scenario you are referring to here? As a Rails core alumni who helped work on the asset pipeline (and whose product uses Rails today), I don't understand it.

[bmeck]

CC: @ljharb

I am no rails asset pipeline expert, but my understanding of the problem is with asset pipelines being given files directly, only working with the file contents and file name.

[ljharb]

Our Rails app does not have a JS runtime made available to it, and as such, we wouldn't be able to determine within Sprockets whether a file is a module or a script (inside an overridden ".js" engine, for example). Using .mjs lets us make a .mjs engine that unconditionally expects ES modules.

[wycats]

Our Rails app does not have a JS runtime made available to it, and as such, we wouldn't be able to determine within Sprockets whether a file is a module or a script (inside an overridden ".js" engine, for example). Using .mjs lets us make a .mjs engine that unconditionally expects ES modules.

Why wouldn't sprockets be able to find the associated package.json (through symlinks if appropriate), and apply a policy based on that?

[ljharb]

Ah - my comment was aimed mostly at the concept of parsing (which neither of you are proposing - sorry).

For "manifest" versus "extension", the difference would amount to whether we had to override the default .js engine with a complex one that looked things up in the manifest (package.json), and branched to "script or module", versus whether we had to simply define a .mjs engine for modules and leave the existing .js engine alone for scripts.

[wycats]

For "manifest" versus "extension", the difference would amount to whether we had to override the default .js engine with a complex one that looked things up in the manifest (package.json), and branched to "script or module", versus whether we had to simply define a .mjs engine for modules and leave the existing .js engine alone for scripts.

The existing .js and .es6 code is already non-trivial. I don't think processing a package.json and branching would be significantly worse (I asked at RailsConf and people generally thought it would work out nicely to process the package.json).

[ljharb]

Yeah I don't think the Sprockets thing is particularly relevant to extension vs manifest - I'd primarily used that as a reason to disqualify parsing. I think "extension" lends itself to a cleaner implementation, for both Sprockets engines and require.extensions polyfills, but since both are more or less one-time costs, I don't think it sways the choice much.

[wycats]

@ljharb in that case I'm going to close this issue and open a pull request to eliminate that argument from the current summary. Cool?

[ljharb]

SGTM.