This is not an issue specific to this plugin, this is an issue that is caused due to some design decisions made in Parcel. Specifically(as mentioned above) the decision not to transpile packages in the node_modules folder. You can see the issue in their repository here: https://github.com/parcel-bundler/parcel/issues/1655

I’m subscribed to that issue, and to other issues regarding HMR, and will update this plugin when possible. Until then there is nothing we can do… EDIT: Updated the link to the issue, accidentally linked a different one.

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.

This might be caused by the way babel transforms the svelte output.

For example one of my components outputs this text in the class definition.

class StyleGuide extends SvelteComponentDev {
	constructor(options) {
		super(options);
		init(this, options, instance, create_fragment, safe_not_equal, {});

		dispatch_dev("SvelteRegisterComponent", {
			component: this,
			tagName: "StyleGuide",
			options,
			id: create_fragment.name
		});
	}
}

Babel and webpack turn it into this gobbledegook where this function _classCallCheck throws that error.

var StyleGuide = /*#__PURE__*/function (_SvelteComponentDev) {
  _inherits(StyleGuide, _SvelteComponentDev);

  function StyleGuide(options) {
    var _this;

    _classCallCheck(this, StyleGuide);

    _this = _possibleConstructorReturn(this, _getPrototypeOf(StyleGuide).call(this, options));
    (0,svelte_internal__WEBPACK_IMPORTED_MODULE_15__.init)(_assertThisInitialized(_this), options, instance, create_fragment, svelte_internal__WEBPACK_IMPORTED_MODULE_15__.safe_not_equal, {});
    (0,svelte_internal__WEBPACK_IMPORTED_MODULE_15__.dispatch_dev)("SvelteRegisterComponent", {
      component: _assertThisInitialized(_this),
      tagName: "StyleGuide",
      options: options,
      id: create_fragment.name
    });
    return _this;
  }

So, I made a babel config containing some customizations for @babel/preset-env. npm install core-js and useBuiltIns are probably not necessary. That’s just how my setup goes.

const babelrc = {
  presets: [
    [
      "@babel/preset-env",
      {
        corejs: 3,
        targets: {
          browsers: ["defaults"]
        },
        useBuiltIns: "usage",
        /*

        Svelte breaks if this tries to transform the classes. It calls these babel
        methods and then throws.

        + _classCallCheck
        + _getPrototypeOf

        */
        exclude: ["transform-classes"]
      }
    ]
  ]
};

module.exports = babelrc;

It needs a little more investigation to find out if the svelte output or the babel transform are to blame. Based on my work here I don’t think it’s an error with DeMoorJasper/parcel-plugin-svelte.

Was this helpful?

Do we need to talk to anyone from the svelte team or do you think it’s just babel junk?

@edm00se I thought you might need this for your template.

Related links: https://babeljs.io/docs/en/babel-plugin-transform-classes https://stackoverflow.com/questions/36577683/babel-error-class-constructor-foo-cannot-be-invoked-without-new

If you don’t want to use the browserslist solution, I wrote a Parcel plugin that forces a Babel transform on certain JS assets:

ForceBabel.js

const fs = require('@parcel/fs');
const babel = require('@babel/core');
const JSAsset = require('parcel-bundler/src/assets/JSAsset');

// Only run Babel on Svelte source files
const babelConfig = {
  include: ['node_modules/svelte'],
  plugins: ['@babel/plugin-transform-classes']
};

module.exports = class ForceBabel extends JSAsset {
  constructor(...args) {
    super(...args);
  }
  // This overloads the JSAsset's`load` function.
  // It transforms the JS file immediately after reading it, 
  // before Parcel has done anything.
  async load() {
    const code = await fs.readFile(this.name, this.encoding);
    const transformed = babel.transformSync(code, {
      filename: this.name,
      ...babelConfig
    }).code;
    return transformed;
  }
};

build.js

const Bundler = require('parcel-bundler');

const bundler = new Bundler(`src/js/main.js`);

// This is how you add a plugin to Parcel
const path = require.resolve('./ForceBabel.js');
bundler.addAssetType('js', path);
bundler.addAssetType('mjs', path);

bundler.bundle();

If you want to use the Parcel CLI instead of the Node API, you can put ForceBabel.js in a local directory with a package.json, call it parcel-plugin-force-babel and run npm i file:./parcel-plugin-force-babel .

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… 😓

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.

I using this temprorary workaround (thx @icopp for comment) for solve the bug. It just trigger a transpilation svelte module via Babel (I hope it will be fixed in next releases of Parcel)

package.json:

{
  "scripts": {
    "postinstall": "cpy --rename=.browserslistrc .browserslistrc.packages node_modules/svelte"
  }
}

.browserslistrc.packages:

last 1 chrome versions

Maybe this has been mentioned before, but babel and typescript both have options to allow transpiling of certain node_modules. If parcel would respect what the app has defined in their babel or typescript config files, then apps would have a better workaround.

example within a tsconfig.json file:

{
    "compilerOptions": {
      "module": "es2015",
      "target": "es5",
      "downlevelIteration": true,
      "allowJs": true,
      ...
    },
    "include": [
        "./*",
        "./node_modules/lit-html/**/*",
        "./node_modules/lit-element/**/*",
      ],
    ...
}

@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)

I really wish there was an option to transpile node_modules. Can Parcel read read node_modules only once and utilize the cache to check if anything has changed? I don’t like the idea of assuming all node_modules are already “standard js”.

@blairn you can use the workaround by @orlov-vo

_{Sent with GitHawk}

@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.