Closed keeffEoghan closed 2 years ago
The reason that glsl-easings
appears to be the culprit is the
"engines" {
"node": "..."
}
line which causes Parcel to not bundle node_modules (so that glsl-easings/back-in
import in GLSL is also theoretically excluded). So you need to remove that in any case.
Actual bug: https://github.com/parcel-bundler/parcel/pull/7263
Can confirm this now works correctly in today's v2.0.1
release!
Also thanks @mischnic, I learned about the engines
etc config today - though it seems that this now works with that field there anyway, doesn't seem to need node_modules
to be bundled! (At least for my test)
Ah, however, it fails with a new error when attempting to run parcel build ...
(rather than the dev server parcel ...
which works now); the error is:
🚨 Build failed.
@parcel/transformer-glsl: Got unexpected null
Error: Got unexpected null
at nullthrows (.../node_modules/nullthrows/nullthrows.js:7:15)
at resolve (.../node_modules/@parcel/core/lib/Transformation.js:578:100)
at async Depper.resolve (.../node_modules/@parcel/transformer-glsl/lib/GLSLTransformer.js:72:26)
Since this is only with production build, I tried again with --no-scope-hoist
/--no-optimize
/--no-content-hash
, but both scripts give identical errors; of these 3 scripts only start
works:
{
"scripts": {
"start": "parcel --log-level verbose ./src/index.html",
"dev": "parcel build --log-level verbose ./src/index.html --no-scope-hoist --no-optimize --no-content-hash",
"build": "parcel build --log-level verbose ./src/index.html"
}
}
Any ideas?
I only get that with engines.node
(which as I've said should be removed)
(But that error message is not ideal)
Right you are, I got overconfident seeing the start
command work with engines
, should've rechecked from scratch - all working now, thank you so much :)
Also, adding this to package.json
lets you keep the engines
field (I use it to indicate what versions of external/global tools I used with a project):
"targets": {
"default": {
"engines": {}
}
}
🐛 bug report
Parcel v2 fails to correctly resolve
glslify
nested vendor dependencies (from e.g:node_modules
).This behaviour worked correctly in v1.
However, the
@parcel/transformer-glsl
introduced in #3352 fails to correctly resolve nested dependencies in vendor dependencies.🎛 Configuration (.babelrc, package.json, cli command)
For both versions, the initial configuration is:
package.json
(devDependencies
differ with each setup)src/index.js
src/frag.glsl
src/f.glsl
src/a/b.glsl
.yarnrc.yml
(does not use PnP mode)See also
glsl-easings/back-in.glsl
, which has no nested imports.See also
glsl-easings/bounce-in.glsl
, which has a further nested import.Each setup also has a slightly different
src/index.html
entry-point, as shown in the below sections.🤔 Expected Behavior
Parcel
glslify
transform should correctly resolve all nested dependencies, including those in vendor (e.g:node_modules
) directories, to produce built GLSL code. The Parcel v1 (parcel-bundler@1.12.5
)glslify
transform behaves correctly for nested vendor dependencies.Installed and run with:
The above code should print correct code similar to this to the browser console:
This setup adds to the above
devDependencies
for Parcel v1:package.json
This setup uses the following HTML entry-point (without script
type="module"
):src/index.html
😯 Current Behavior
The Parcel v2 (
parcel@2.0.0
)glslify
transform fails to resolve nested vendor dependencies (e.g:node_modules
), though it correctly handles nested project dependencies (within the project's own directories).Installed and run with:
The CLI displays an error message, showing paths that seem to be relative to the project directory, not the vendor (e.g:
node_modules
) directories as would be expected:This setup adds to the above
devDependencies
for Parcel v2:package.json
This setup uses the following HTML entry-point (with script
type="module"
):src/index.html
Note that commenting out this line in
src/f.glsl
:Causes the build to succeed and the following to be printed to the browser console:
This demonstrates that the problem is likely with only nested vendor dependencies, not the project's own local dependencies.
💁 Possible Solution
I expect this probably has something to do with the way vendor paths are resolved in the
glslify
transform for Parcel v2; I had a look but am not familiar enough with the APIs to attempt a fix:glslify
transform setup for Parcel v1 atpackages/core/parcel-bundler/src/assets/GLSLAsset.js
(seems correct).glslify
transform setup for Parcel v2 atpackages/transformers/glsl/src/GLSLTransformer.js
(seems incorrect).🔦 Context
This issue has caused me to upgrade to Parcel v2, fail to solve the problem after following misleading error messages, then roll back to v1 - at least 3 times over the last year. It blocks me from migrating any WebGL projects to Parcel v2, which in turn prevents me from benefitting from any of the latest developments and up-to-date support of Parcel v2. It seems that a simple
glslify
transformer fix here in v2, looking at a correctly-working setup in v1, would solve all these issues.💻 Code Sample
Included throughout above.
🌍 Your Environment
Included throughout above.