13 Matching Annotations
- Nov 2020
-
www.npmjs.com www.npmjs.com
-
Create aliases of directories and register custom module paths in NodeJS like a boss
Tags
Annotators
URL
-
-
stackoverflow.com stackoverflow.com
-
In contrast to import (which handles 1+2 pretty much the same way, but would send you looking in node_modules right away) path 'module' indeed means your project root for paths without a need to resolve, like output.path in your webpack config... and: (on resolving) Only 3 is subject to resolve.root and resolve.moduleDirectories resolving, see webpack docs here
-
- Oct 2020
-
rollupjs.org rollupjs.orgRollup1
-
If you do want to include the module in your bundle, you need to tell Rollup how to find it. In most cases, this is a question of using @rollup/plugin-node-resolve.
-
- Sep 2020
-
stackoverflow.com stackoverflow.com
-
// resolve dependencies from node_modules
-
-
rollupjs.org rollupjs.orgRollup2
-
Resolve imports to module ids (i.e. file names) using the same plugins that Rollup uses, and determine if an import should be external. If null is returned, the import could not be resolved by Rollup or any plugin but was not explicitly marked as external by the use
-
Rollup will only resolve relative module IDs by default.
-
-
github.com github.com
-
globals are assumed to have their field value on the window object and can be referenced inside the bundle by their field name globals: { name: 'Value', }, assumes that some other script tag or whatever establishes window.Value and the emitted umd bundle for example, calls the factory like factory(global.Value). So globals is just stuff to bring into the factory on the globals object. It doesn't even make it "global" inside the bundle. Basically, the resolver does not check the globals object during the loading process. The resolver needs to be told how to link these globals and that's what the external option is for. external: ['name'], Then you can reference it like import myName from 'name'; myName();
-
we've learned why you might want to use external but not globals: libraries. We've started to factor some of our client-side JS as libraries to share between projects. These libraries import $ from 'jquery'. However they don't want to presume how that import might be "fulfilled". In most projects it's fulfilled from a global i.e. a script loaded from a CDN. However in one project it's fulfilled from a local copy of jQuery for reasons I won't get into. So when these libraries bundle themselves for distribution, as ES6 modules, they mark 'jquery' as an external and not as a global. This leaves the import statements in the bundle. (Warning: Don't bundle as an IIFE or UMD, or Rollup will guess at fulfilling the import from a global, as @Rich-Harris mentions above.)
-
-
github.com github.com
-
Since most CommonJS packages you are importing are probably dependencies in node_modules, you may need to use @rollup/plugin-node-resolve:
-
-
github.com github.com
-
basarat.gitbook.io basarat.gitbook.io
-
Base directory to resolve non-absolute module names.
-
-
www.typescriptlang.org www.typescriptlang.org
-
stackoverflow.com stackoverflow.com
-
Let's say you import { Interface } from "api/interfaces", from source file /src/views/View.ts. Typescript would then look for the module in the following paths: /src/views/api/interfaces.ts /src/api/interfaces.ts /api/interfaces.ts
-