parcel watch src/pages/**/*.html
works as expected, loads page.
parcel build src/pages/**/*.html
throws error in client.
Should work without errors like parcel watch
throws an error on client:
Uncaught Error: Cannot find module '124e7827022519669c1bd7f8546b7300'
at r.parcelRequire.r.parcelRequire (app.2e65e441.js:1)
Thought it was because of code splitting. Tried it without, still doesn't work (also removed .parcel-cache and dist) before build.
Is it possible that parcel removes dependencies during optimize which doesn't happen in parcel watch?
| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 2.0.0-alpha.3.2
| Node | 14
| npm/Yarn | 6.14.4
| Operating System | MacOS 10.15.2
Is it possible that parcel removes dependencies during optimize which doesn't happen in parcel watch?
Yes. parcel watch behaves like parcel serve but without the dev server. It doesn't do parcel build continuously.
Have you tried it with npm i -D parcel@nightly? If it still fails, could you share a small (complete) code example where this error occurs?
Actually the @nightly throws the same error.
I'll check if I can make a small code example. The project where it occurred is pretty big with lots of module imports and I cannot really pinpoint where exactly it is happening.
I dug some more around. I got different errors when I excluded certain imports.
With the --no-scope-hoist flag it builds fine. Could it be that parcel watch has that flag set by default?
Here is an example example.zip:
run npm install
run one of these
// uses parcel watch -> success
npm run start:dev
// uses parcel build -> fail
npm run start
md5-55f9f2963520a2ab190a753606cd0c82
// uses parcel build --no-scope-hoist -> success
npm run start:work
Are you getting clazz.createProperty is not a function?
This seems to be an interop problem between typescript decorators and babel decorators, works with this .parcelrc to use tsc (you can remove your babelrc with this)
{
"extends": "@parcel/config-default",
"transformers": {
"*.ts": ["@parcel/transformer-typescript-tsc"]
}
}
Oh, I didn't know @parcel/transformer-typescript-tsc wasn't enabled by default.
Does the element render (showing hello world in red) for you? With that setup (and without babel) it seems that the transpiled js file is empty (except parcel boilerplate).
Does the element render (showing hello world in red) for you?
Yes, with these changes:
diff --git .parcelrc .parcelrc
new file mode 100644
index 0000000..e56d797
--- /dev/null
+++ .parcelrc
@@ -0,0 +1,6 @@
+{
+ "extends": "@parcel/config-default",
+ "transformers": {
+ "*.ts": ["@parcel/transformer-typescript-tsc"]
+ }
+}
diff --git package.json package.json
index ea2491a..54db646 100644
--- package.json
+++ package.json
@@ -28,6 +28,7 @@
"@babel/plugin-transform-typescript": "^7.9.4",
"@babel/preset-env": "^7.9.5",
"@babel/preset-typescript": "^7.9.0",
+ "@parcel/transformer-typescript-tsc": "^2.0.0-nightly.240",
"@types/koa": "^2.11.3",
"@types/koa-static": "^4.0.1",
"parcel": "^2.0.0-nightly.240",
removing babel.config.json makes no difference for me.
Ok, removed node_modules and reinstalled and it worked! Thank you so much!
I wonder if @parcel/transformer-typescript-tscneeds to be set by default. The initial problem was, that bundling with watchand build did not behave the same. That transformer solves that problem and if set by default surely would avoid some headache moments.
wonder if @parcel/transformer-typescript-tscneeds to be set by default.
can be closed
Using tsc is probably what you intended to do (also because decorators were enabled in the tsconfig). But this is still a bug in Parcel:
class Element extends LitElement {
@property({ type: String, reflect: true }) content
// ...
}
window.customElements.define("my-element", Element);
This has the same error as your example with scope hoisting enabled.
It turns out that the Element argument in .define() isn't actually the class but the builtin constructor Element, renaming it to XX in the example results in XX is not defined.
Seems to be a bug in the Babel plugin: https://github.com/babel/babel/issues/11506
Closing this, especially since you have a viable workaround.
That Babel bug is fixed in 7.10.5.