Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Class constructor SvelteComponent cannot be invoked without 'new' #44

Open
leny opened this issue Apr 26, 2019 · 13 comments

Comments

Projects
None yet
5 participants
@leny
Copy link

commented Apr 26, 2019

馃悰 Bug Report

Hi, got some strange error with a basic "Hello world" app.

Class constructor SvelteComponent cannot be invoked without 'new', pointing my app.js

馃帥 Configuration (.svelterc, package.json, cli command)

Nothing special.

馃捇 Code Sample

Everything's in the repo, but the code is quite simple :

import App from "./components/app.svelte";

const root = new App({
    target: document.querySelector("#root"),
    props: {},
});

export default root;

and the app.svelte is:

<script>
	let name = 'world';
</script>

<h1>Hello {name.toUpperCase()}!</h1>

馃實 Your Environment

Svelte version ^3.1.0, Parcel version ^1.12.3, plugin version 3.0.0


Thanks in advance!

@GeordieP

This comment has been minimized.

Copy link

commented Apr 26, 2019

I have the same issue.

Adding the following to package.json (as recommended by this comment) get things compiling and displaying on the page:

  "browserslist": [
    "last 1 chrome versions"
  ],

However, HMR throws an error (browser console):

proxy.js:62 Uncaught TypeError: Cannot read property 'apply' of undefined
    at proxyComponent.self.<computed> [as get] (proxy.js:62)
    at proxyComponent._rerender (proxy.js:185)
    at hot-api.js:43
    at Array.forEach (<anonymous>)
    at reload (hot-api.js:43)
    at Object.eval (eval at hmrApply (hmr-runtime.js:153), <anonymous>:104:11)
    at newRequire (main.1f19ae8e.js:47)
    at hmrAcceptRun (hmr-runtime.js:203)
    at hmr-runtime.js:60
    at Array.forEach (<anonymous>)

Manually refreshing the page works fine, so we can provide the --no-hmr CLI option to Parcel and get rid of that issue, but obviously this isn't ideal as we no longer have HMR.

@DeMoorJasper

This comment has been minimized.

Copy link
Owner

commented Apr 27, 2019

I鈥檓 aware of this issue and will try to look into it. If anyone has experience with Svelte compiler or just wants to try to fix this feel free to do so.

Sent with GitHawk

@Mouvedia

This comment has been minimized.

Copy link

commented Apr 30, 2019

Is there a hack/fix that doesn't involve using browserslist?

Repository owner deleted a comment from samuelnovaes May 13, 2019

@madbrain

This comment has been minimized.

Copy link

commented May 14, 2019

This problem seems to be related to parcel-bundler/parcel#1037 and the source from node_modules packages not being transpiled. Svelte v3 (tested with 3.3.0) contains some ES6 syntax (mostly class declarations).
If I understand correctly all the explanations (which I doubt), the correction has to be made on svelte itself 馃槩.

Or as @Mouvedia mentioned, use browserslist in order to get only ES6 code and not mix it with transpiled code.

@DeMoorJasper

This comment has been minimized.

Copy link
Owner

commented May 15, 2019

@madbrain seems like it's the only way. I've tried fixing it in the plugin a little while ago.
Couldn't really figure out a way around this

@Mouvedia

This comment has been minimized.

Copy link

commented May 16, 2019

use browserslist

I don't want to.

If I understand correctly all the explanations (which I doubt), the correction has to be made on svelte itself 馃槩.

@madbrain can you fill it?

@madbrain

This comment has been minimized.

Copy link

commented May 16, 2019

I opened an issue on svelte (sveltejs/svelte#2788).

Hope this would help.

@madbrain

This comment has been minimized.

Copy link

commented May 19, 2019

Well... after some comments on the issue I opened, it seems that browserslist should only be used on applications and not library.

So I spent some more hours of debugging and it seems that the problem is coming from Parcel itself: when an external JS asset is transformed to AST, the minimal amount of babel plugins is computed. But when external module contains no information (browserslist, babelrc, etc.), the target env serves as reference (https://github.com/parcel-bundler/parcel/blob/master/packages/core/parcel-bundler/src/transforms/babel/env.js#L21), which leads to no transpilation at all.

Guys, this is a marathon... 馃槗

@DeMoorJasper

This comment has been minimized.

Copy link
Owner

commented May 19, 2019

@madbrain there has actually been various discussions around libraries needing to explicitly mention their target env as otherwise bundlers have no way of knowing which entrypoint to pick/env to start from. There is unfortunately no standard to this as package.json is not really standardised at all.

There have been some proposals and parcel just tries to figure it out based on all semi-standardised fields like browserslist. Not sure why they don't wanna mention it. But they should.

@madbrain

This comment has been minimized.

Copy link

commented May 19, 2019

Is it the desired behaviour to have no transpilation at all when the external module doesn't provide any hint ?
I got a pending commit (madbrain/parcel@18f9b1f) which correct this behaviour, but it sounds to obvious to really be what you (parcel maintainers) got on your mind.

@DeMoorJasper

This comment has been minimized.

Copy link
Owner

commented May 19, 2019

@madbrain perhaps, imo this would make more sense. but it would slow down Parcel significantly as packages who don't have a browserslist or something similar will all get compiled (and most packages actually do target commonjs, which makes this prob not such a good idea). Which unfortunately is way too many packages. It would be great if tools like babel actually enforced a similar pattern to Parcel and use browserlist file or package.json instead of allowing defining target env in babel. Or at least not encourage it.

This (having no idea what a package targets problem) was actually mentioned in a talk at Google I/O about how package creators could help improve bundle size and in Parcel's case also Bundler performance by using some target field https://youtu.be/-xZHWK-vHbQ?t=2294 (although I'm no fan of their suggested syntax, as it's a very short term solution...)

Anyway the package.json "spec" still has a long way to go before it can actually help improve bundle size and bundler speed. Luckily a lot of people are trying to push these things to become standard including the Parcel team. (unfortunately also leading to multiple specs)

@DeMoorJasper

This comment has been minimized.

Copy link
Owner

commented May 19, 2019

A link to my original PR on this with a bunch of comments why this isn't a good idea and possible solutions: parcel-bundler/parcel#2073

@Mouvedia

This comment has been minimized.

Copy link

commented May 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.