Skip to content
New issue

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

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Error: Unexpected token export #112

Closed
nicolasdezena opened this issue Aug 8, 2019 · 7 comments
Closed

Error: Unexpected token export #112

nicolasdezena opened this issue Aug 8, 2019 · 7 comments

Comments

@nicolasdezena
Copy link

nicolasdezena commented Aug 8, 2019

Hi guys,

I have an error when i put
const { Model } = require("objectmodel")

Error:

billing-shopback-api | export { Any, ArrayModel, BasicModel, FunctionModel, MapModel, Model, ObjectModel, SetModel };
billing-shopback-api | ^^^^^^
billing-shopback-api |
billing-shopback-api | SyntaxError: Unexpected token export
@sylvainpolletvillard
Copy link
Owner

Hello,

Since v4, ObjectModel is distributed as ES Module, and no longer CommonJS. See release notes here: https://github.com/sylvainpolletvillard/ObjectModel/releases/tag/v4.0.0

import { Model } from "objectmodel"

@gotjoshua
Copy link
Contributor

gotjoshua commented Aug 15, 2019

I also get a similar error in the legacy build for meteor, even though i am using the correct syntax.
There i think it is due to meteor's transpiling but I don't know how to get around it (so i am stuck on 3.7.7).

@sylvainpolletvillard
Copy link
Owner

yeah, unfortunately the transition from CommonJS to ES modules is not super smooth, mainly because of Node.js modules plan and bundler/transpiler issues.

I like the idea of distributing ESM, because it lets the final user use its own build tools, decide which environments to target with @babel/preset-env, and gets great tree-shaking and code elimination thanks to static analysis of ES modules. It's more initial work for the library consumer, but at the end he gets a custom build that is optimized for his specific needs. ESM also improves the developer experience with better autocompletion, for example, compared to a UMD bundle.

In the future, we can expect all the browsers/environments/tools to fully adopt ES modules by default and just work. Nethertheless, I hesitated when publishing v4 if this move was too early or not. Do you think I should still provide a UMD bundle for v4 ? Or let you do it by yourself ?

@rpstreef
Copy link

rpstreef commented Sep 4, 2019

Trying to set this up with Node10 and babel proved to be an exercise in frustration.

So yes a commonjs variant would be appreciated.

@sylvainpolletvillard
Copy link
Owner

In the meantime, I found a way to fix this without having to provide a UMD bundle myself. The pika.dev service is providing UMD versions of my library for free. You can take it from their CDN here: https://umd.cdn.pika.dev/objectmodel/v4

Docs have been updated, and you can find a usage example here too: https://github.com/sylvainpolletvillard/ObjectModel/blob/master/test/umd.html

@jnreynoso
Copy link

Even with webpack, I get this error.

@sylvainpolletvillard
Copy link
Owner

please check my answers above

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants