Unexpected token { when importing a module - javascript

Here's a codepen
with this import I get the error(10 line index.vue):
import { EffectComposer } from "three/examples/jsm/postprocessing/EffectComposer.js";
so what's going on here? The other ES6 imports are fine.

I commented above about having the same problem. Meanwhile I came across this project and wondered why it works. Long story short, it's configured as a SPA. I tried the same with my project and it works.
So in nuxt.config.js
export default {
mode: "spa",
..
So I guess the problem has to do with server-side rendering.
------ Some notes on Universal Mode ------
Since I wanted to use my app in universal mode I also tried to do conditional import of plugins.
Note that the approach below doesn't work. I do include it though, SPA might not be an option and it could point you in the right direction.
Move
import Vue from 'vue'
import { OrbitControls } from "three/examples/jsm/controls/OrbitControls"
Vue.use(OrbitControls)
into a threeimports.js file in the plugins folder and add
plugins: [
{ src :"~/plugins/threeimports.js", ssr: false},
..
to the nuxt.config.js
I thought OrbitControls should be available from anywhere in the project, but it's not. It has to do with the curly bracket syntax, since the same mechanism works well with other modules that don't use the bracket syntax.

I don't know the structure of the file where you want to import from, but are you trying to import a default or just a module?
Because the default syntax does not have {}. Much like your first import. If what you're trying to import is set as a default export, you need to remove those brackets.
Read about import in the MDN

Related

How to solve the lit build-in directives import error?

Using lit 2.5.0 in combination with vite I run into an issue using the lit build-in directives.
Following the docs I added an import to my lit js component like:
import { when } from 'lit/directives/when';
But when I view the resulting site in the browser I always get a missing package error:
Missing "./directives/when" export in "lit" package
Any suggestions on how to fix this import issue?
You need to include the .js extension as well.
import { when } from 'lit/directives/when.js';
This is needed because that's how it's listed in the "exports" of the package which you can see in the package.json file. https://unpkg.com/lit#2.5.0/package.json
"./directives/when.js": {
"types": "./development/directives/when.d.ts",
"default": "./directives/when.js"
},
Rationale for this is to encourage usage of file extensions in import specifiers so as to not require bloated import maps in the browser to support extensionless imports. Described more in detail https://lit.dev/docs/tools/publishing/#include-file-extensions-in-import-specifiers and https://github.com/WICG/import-maps#extension-less-imports.

Set VS Code autoImports action to use ES syntax

I'm working on a node project in VS Code with a package.json file that has the "type": "module" set. when I type in an export name from another file the autoImport functionality automatically writes the import statement for me; although I would like it to write the import statement using ES modules syntax. currently, it imports it using require which doesn't make much sense since I wrote the export using ES syntax. how do I get VS Code to behave this way?
// example.js
export default function reader() {}
this is how the import works currently
I use this plugin for auto import. Maybe this plugin will help you too.

Can't make vue-slick-carousel work from CDN

I'm trying to use it in a very small app using the CDN script:
https://unpkg.com/vue-slick-carousel
with no success.
I'm new to vue.js and I'n not sure if I have to import it or anything.
The documentation says I have to import it: Vue-slick-carousel
IT should be like this but I can't make it work:
import VueSlickCarousel from 'vue-slick-carousel'
// optional style for arrows & dots
import 'vue-slick-carousel/dist/vue-slick-carousel-theme.css'
export default {
name: 'MyComponent',
components: { VueSlickCarousel },
}
The test is in this codepen
Am I missing something?
You can't 'import' from a CDN script in the way you've done. You can access the window variable and assign it to the component. By using a CDN, it becomes bound to the window.
So components: { VueSlickCarousel : window['vue-slick-carousel'] } without the import VueSlickCarousel from 'vue-slick-carousel' would solve that portion of your question.
The issue is that, the code referenced in the example is for packaged installs, and not a CDN. If you can install via npm install vue-slick-carousel, or yarn add vue-slick-carousel, then these problems would resolve themselves.
Edit: As mentioned in the comments, the component should be kebab-case in your HTML. <vue-slick-carousel> ... </vue-slick-carousel> instead of <VueSlickCarousel> ... </VueSlickCarousel>
This is in line with the style guide provided in the Vue docs seen here
In most projects, component names should always be PascalCase in single-file components and string templates - but kebab-case in DOM templates.

Using Vue Design System in Nuxt is throwing errors about export in system.js

I am trying to get the components imported into a Nuxt project, following the steps here:
https://github.com/viljamis/vue-design-system/wiki/getting-started#using-design-system-as-an-npm-module
Nuxt does not have a main.js (everything is plugin based), so what I have done is create a "plugin" and then do the import code in there like so (Nuxt recommends this for other libraries too and works fine):
vue-design-system.js
import Vue from 'vue'
import system from 'fp-design-system'
import 'fp-design-system/dist/system/system.css'
Vue.use(system)
Then in my config I do (removed other code in config):
nuxt.config.js
module.exports = {
css: [
{ src: 'fp-design-system/dist/system/system.css', lang: 'css' }
],
plugins: [
{ src: '~plugins/vue-design-system', ssr: true }
]
}
When I run npm run dev in my theme, it builds, but I get a warning:
WARNING Compiled with 1 warnings warning in
./plugins/vue-design-system.js 7:8-14 "export 'default' (imported as
'system') was not found in 'fp-design-system'
Seems to have an issue with the generated system.js regarding the export (the command npm run build:system).
In my page on screen I get the following error when trying to use a component in the design system:
NuxtServerError Cannot find module
'fp-design-system/src/elements/TextStyle' from
'/Users/paranoidandroid/Documents/websites/Nuxt-SSR'
If I hard refresh the page, I then get another message:
NuxtServerError render function or template not defined in component:
anonymous
Any idea what's happening here? It would be really great to get this working somehow.
At this current time, I'm not sure if it's a Nuxt issue or a Vue Design System issue. I think the latter, just because the Nuxt setup I have right now is very bare-bones...so it's not something else causing this.
Thanks.
Repository on GitHub:
Here is the repo for my "theme", but in order to get this going, you will need to create a design system separate from this with the same name and follow the steps to use the design system as a local (file) NPM module.
https://github.com/michaelpumo/Nuxt-SSR
console.log of system (from the JS import statement)
As for your first error (""export 'default' (imported as 'system') was not found in 'fp-design-system'"), the UMD built JS from vue-design-system does not export a "default" object. But you can simply workaround the issue by importing it as:
import * as system from 'fp-design-system'
instead of:
import system from 'fp-design-system'
Then another issue comes quickly as you noticed in your comments: "window is not defined", due again to the UMD built JS that expects window to be globally available, instead of the usual trick to use this (which equals window in a browser). Therefore as it is, the build is not comptible with SSR.
You could however slightly rework the built JS by replacing the first occurrence of window by this, but I am not sure if the result will still work.
Most probably you should better keep this module for client rendering only.
It seems Vue is looking for the ES6 pattern for importing module, which you should use for external javascript modules/files.
in ES6 it is
export default myModule
in ES5 it was
module.exports = myModule
Hope it will help.

Why do named imports cause slower builds and larger output?

I was looking at the material-ui documentation and saw the below comment about how to properly do an import in ES6.
What is the technical reason that doing a named import is slower and causes larger output?
Notice that in the above example, we used:
import RaisedButton from 'material-ui/RaisedButton';
instead of
import {RaisedButton} from 'material-ui';
This will make your build process faster and your build output smaller. For a complete mapping of Material-UI components to import, see /index.js inside the Material-UI npm package root directory.
That's not exactly enough context to see what's happening.
There are two separate things going on.
Default exports are typically going to be bigger than property exports.
export default ObjectWithAllKindsOfStuff {}
export function someFunction () { }
The second one is going to be smaller, practically 100% of the time, if they're in the same file.
Importing a single function from #angular/core is going to require opening a whole lot more files (taking longer) than importing everything from #angular/a/b/c/d/e/f.js.
If you are in the root folder's index.js, and you export * from './a', and in there, you export * from './b', et cetera... then for WebPack or Rollup or whatever, it has to load all of the files below, to figure out what each one exports, so it can tell where the function actually lives.
Their example is actually unfair, in that using the import { x } from 'package/SubPackage/SubSubPackage'; is going to be even smaller than import All from 'package/SubPackage/SubSubPackage';, but if you import { x } from 'pacakge'; and it has to go all the way through every folder, spidering through all of the exports, to figure out which file the function comes from, that's the comparison they're really making - it has nothing to do with the export {property} from versus export Namespace from if they're both talking about the same file, in the same subfolder.

Categories

Resources