browserify / crypto-browserify

partial implementation of node's `crypto` for the browser
MIT License
653 stars 199 forks source link

Remove browser from package.json. #205

Closed tmpfs closed 3 years ago

tmpfs commented 3 years ago

This doesn't make sense for a package that is meant to be a shim for the browser and also it creates a segfault when using spack and aliasing crypto to crypto-browserify.

ljharb commented 3 years ago

It makes perfect sense, since it might also be used in node too.

What is spack?

tmpfs commented 3 years ago

I disagree that it makes sense. The browser field is for ESM imports and CJS require calls within the package but crypto-browserify never imports or requires the crypto module, therefore the field is redundant. More information about the browser field specification.

The spack bundler is from the swc project: https://swc.rs/

ljharb commented 3 years ago

No, the browser field is NOT and never has been for ESM imports - it is ALWAYS and ONLY for CJS.

If spack breaks on it, then spack is broken. This package has been configured this way since npm existed.

tmpfs commented 3 years ago

No, the browser field is NOT and never has been for ESM imports - it is ALWAYS and ONLY for CJS.

If spack breaks on it, then spack is broken. This package has been configured this way since npm existed.

Not much point discussing this further as you don't seem to understand the thrust of my point that the browser field applies in the context of this package. There is absolutely no reason that browser should only be applied to commonjs after all it is about the runtime environment not the way a module is referenced.

ljharb commented 3 years ago

That is what the specification for the browser field says, so you’re incorrect.