Hi! If package name like "name:pkg" dynamically import isn't working :(
But if package name is just "pkg" all working okay.
Error:
Exception while invoking method '__dynamicImport' Error: ENOENT: no such file or directory, open '/home/user/project/.meteor/local/build/programs/web.browser/dynamic/node_modules/meteor/name:pkg/client.js'
But I have file in /home/user/project/.meteor/local/build/programs/web.browser/dynamic/node_modules/meteor/name_pkg/client.js ( name_pkg instead of name:pkg )
P.S: if I rename my package to name-pkg all works correctly.
Thanks for reporting a bug. Providing a reproduction, as requested when opening an issue and in reporting a bug would make it easier to test a fix for this and save someone from having to go to the effort of building a test application. For example, this could be related to what I discussed in https://github.com/meteor/meteor/issues/7661#issuecomment-263936772 and a reproduction would make it easy to test the fix.
Running into this same issue. We have like a hundred local packages with :
in their names... Renaming the ones we use for dynamic imports, but it ain't nice.
This was easy enough to reproduce without a formal repro repo, and fortunately could be fixed with a new (patch) version of the dynamic-import
package, specifically [email protected]
. Running meteor update dynamic-import
should fix the problem immediately!
Note (especially @abernix @hwillson): for future reproductions involving dynamic imports, it may be easiest/best for the affected developer to submit a quick PR that adds a failing test to the dynamic-import
test app, as I did in the commit you see above.
You can run the dynamic-import
test app as a self-test (from a checkout) with ./meteor self-test 'dynamic import'
, or you can run the app directly (for easier debugging):
cd path/to/meteor/tools/tests/apps/dynamic-import
meteor npm install
meteor test --full-app --driver-package dispatch:mocha-browser
Most helpful comment
This was easy enough to reproduce without a formal repro repo, and fortunately could be fixed with a new (patch) version of the
dynamic-import
package, specifically[email protected]
. Runningmeteor update dynamic-import
should fix the problem immediately!Note (especially @abernix @hwillson): for future reproductions involving dynamic imports, it may be easiest/best for the affected developer to submit a quick PR that adds a failing test to the
dynamic-import
test app, as I did in the commit you see above.You can run the
dynamic-import
test app as a self-test (from a checkout) with./meteor self-test 'dynamic import'
, or you can run the app directly (for easier debugging):