Ah, yeah this sounds like an issue that we don't support Alpine builds.

I would suggest cargo install chompbuild in this case.

Thanks for posting. Yes resources have not been implemented in this project yet. It was top of my list until it wasn't! Will leave this one open to track.

I've posted a follow-up comment on the naming discussion in https://github.com/nodejs/node/issues/49541#issuecomment-1738235575.

To reiterate my concern about the name here - having a flag that does not do what it sounds like it does is a recipe for user confusion. If I see a flag called --experimental-type=module and run node --experimental-type=module x.js where depending on various complex rules I don't understand it may or may not actually execute the module under that type, creates a very bad user experience by setting up the possibility for a confusion leading to a mismatch between expectations and the actual model.

Therefore my request is that we use any name other than --experimental-type or --type. Both --default-type and --implicit-type are fine by me.

Since this is now blocking https://github.com/nodejs/node/pull/49869, and @GeoffreyBooth is unable to change the PR without consensus, I would like to ask those participating here to urgently help in finding consensus on a suitable name.

Those who have already voted for --type (@JakobJingleheimer ?) can you clarify if you would be able to change your opinion?

And if anyone has strong opinions for or against here please do share, since not knowing which alternatives are viable is hindering progress currently.

--implicit-type would also work for me here in being a qualifying name. If we want short flags, we could add a short flag alias for the module value or similar.

I don’t think of this as any different than the type field itself.

I understand the reasoning you're making, but it's still not a strong argument to me. We should evaluate the clarity of the name on its own merits not relatively.

--experimental-default-type remains my preference for clarity.

Okay, let's start with this version, and iterate with feedback if we need to.

the default value of --default-type is now module

Semantically this is entirely correct in it being a default of a default, but you would usually just say the "default type" is now module.

My concern specifically was about users wondering why node --experimental-type=commonjs x.js doesn't work when you have a package.json of "type": "module". Thinking of it as setting the type is definitely wrong and confusing, as it is very much setting a default.

Very interesting discussion, reimagining packaging conventions is surprisingly hard, as it becomes clear how much really is just convention over specification and how much cross-interaction there is to consider.

I like the sentiment of simplifying on strings. One problem with overloading the strings too much is that normalization starts to become a little more ill-defined. The unstructured nature of the string still requires parsing, resolution and normalization operations in tooling, and so structure and convention is very quickly needed again.

If seeking to reduce structure, a middle ground might be tagged strings + arbitrary structured key / value metadata:

Starting with the existing example:

(import "foo" (func ...))
(import "interface(foo:bar/baz)" (func ...))
(import "contents(integrity=xx)" (func ...))
(import "url(xx, integrity=xx)" (func ...))
(import "relative-url(foo, integrity=xx)" (func ...))
(import "locked-dep(foo:bar/baz, integrity=xx)" (func ...))
(import "unlocked-dep(foo:bar/baz)" (func ...))

Then expressing that in the spec primitivies of tagged strings (name | id | url) and arbitrary attributes:

(import (name "foo") (func ...)) ; kebab name
(import (id "foo:bar/baz") (func ...)) ; IDs as distinct from names and URLs
(import (url "sha256:xx") (func ...)) ; content addressing integrity via URL-like conventions
(import (url "xx") (attr integrity "xx") (func ...)) ; integrity is an attribute if not content-addressing
(import (url "foo") (attr integrity "xx") (func ...)) ; relative url is still a url
(import (id "foo:bar/baz@1.2.3") (attr integrity xx) (func ...)) ; locked deps as fully constrained ids with exact versions
(import (id "foo:bar/baz") (attr constraint "^1.2") (func ...)) ; unlocked deps as non-exact ids with constraints

The important point is the spec doesn't need to specify the conventions and details, just that there are tagged strings and attributes of the formst:

1. name | id | url string: the kebab name, interface name, absolute or relative url depending on which case applies. Structure could possibly even be simplified further to just be strings without tagging via conventional string parsing rules, where ids are a subset of URLs of sorts.
2. Non-identifying key / value metadata attributes for imports only: do not form part of the instantiation argument, do not form part of the identity, but can be used to authoritatively drive linking and resolution information. The encoding as just a list of arbitrary key value string pairs.

While metadata keys can be arbitrary, we already have a bunch defined so then as conventions emerge they can be explicitly specified and reserved for very specific scenarios. The benefit of metadata attributes then being able to balance having some structure while evolving conventions over time as needed.

Are you referring to the validation here? Validation of the entire binary seems like it may incur an unnecessary performance cost when the magic bytes \0asm are already sufficient.

The URL at this position would be fully normalized, so that .. segments cannot appear. I posted before reading your comments, but address the case you just brought up in https://github.com/nodejs/node/pull/49869#discussion_r1336530325.

While there are still various edge cases here, overall this seems like the right kind of tradeoff to me, especially considering this will be an opt-in experimental flag.

If there are any concerns about cases where developers happen to be nesting node_modules for whatever reason, I just wanted to note that there could be a slightly more constrained version of this check based on the following rules:

• Apply getPackageBase to the url to get the package.json base
• If that package.json file is not the base of a package - ie it is not the node_modules/pkg/package.json or node_modules/@pkg/scope/package.json file, then we could allow switching that default, so that an inner package.json might also be covered by the switch

Could be worth considering depending on how the feedback goes.

This seems to be the better naming IMO. Using the term "default" to describe this mode switch I think may be much more clarifying since this doesn't override existing configurations.

When there's no process.env, the check above fails. This just guards it.

Thanks for posting, agreed we should add a button or figure out how best to integrate in this case. Contributions welcome.

Also documentation should be added in https://github.com/jspm/jspm-cli/tree/main/docs, which would then get added to the site.

What happens if entry is not provided? Surely we always need one?