require function is used in a way in which dependencies cannot be statically extracted

[bratushka]

Hello,

I've posted question on StackOverflow regarding one library, which complains about your library when I try to run tests. It looks like the problem, which was fixed in 1.1.1, but I use 1.1.1 and the problem persists. I've also created a small project so you can reproduce it.

Can you fix this bug or at least make sure, that this is not a bug in your library?

[zbennett10]

I am having the same issue!

ERROR in ./~/sortobject/index.js
Module not found: Error: Can't resolve 'editions' in 'C:\WASP\wasp\waspui\node_modules\sortobject'
resolve 'editions' in 'C:\WASP\wasp\waspui\node_modules\sortobject'
Parsed request is a module

[wesleytodd]

Me too. We use browserify to bundle an single executable file in production environments. Because the editions package tries to read the package.json of this package.json, it fails to start. I can open an issue with that package if you want, but this was my first stop. Not sure how you could remove that dependency, but we will be removing everything that depends on this module because of this issue. But would love to know when it is fixed so we could use this.

[balupton]

Can someone post up a repository that reproduces this problem. The information above is not enough for me to know what is the cause of this.

This package uses https://github.com/bevry/editions to specify the editions that this package supports, this is then rendered in the readme - https://github.com/bevry/sortobject/blob/c521f07670eab0f86394195876fe6d249b97d830/README.md#editions - our source is coded in ESNext and it is compiled down to ES2015.

The main field in package.json points to the editions autoloader that selects the best edition based on what your environment supports.

The browser field in the package.json file points directly tot he ES2015 edition, avoiding the editions autoloader.

If the issue is related to a bundler - and you want to use a particular edition, you can use the information rendered in the readme with your bundler configuration. Normally bundlers would use either the module or browser field when applicable. But it seems @wesleytodd's use case is turning support for that off - algolia/react-element-to-jsx-string#25 (comment) - which requires manual configuration.

It would be great if the bundlers supported the editions field directly, and then could take in multiple source editions, and compile for the correct target. However, that hasn't happened it: https://youtu.be/IAB8_UlcNWI - still, the editions field and the editions loaded, individually, or even together, are a great step up from the usual practices of only supporting the highest common denominator or the lowest. Instead, the consumer currently, and eventually the bundler, can autopick the best source edition to use for the target environment. Right now for our packages that use editions, we use the browser field for our lowest common denominator with require syntax (available on this package), and module for our highest common denominator with the import syntax (not available on this package).

I'm not sure what else I can do, besides probably mentioning the browser field in the editions section in the readme. As well as possibly including some links to different bundler configurations for picking a specific edition. <<< These would actually be pretty sweet, especially as a website where you select the package, select the edition, select the bundler, and you get the config needed.

[balupton]

Try again with v1.2.0