I have two Angular2 projects using webpack as module bundler and typescript.
Aiming to share code between, I split some of the source code and created a symlink to this 'external' source code from each of this two projects.
After doing this the "symlinked code" can not resolve the imports properly.
below a "hello world" project to shows my concerns.
https://github.com/datracka/angular2-symlink-issue
This project runs straight forward BUT if you remove the given src folder and create a symlink to another src folder with the same source code BUT located at /another/path/src then you get a compiler error:
ERROR in .-shared/src/main.ts
Module build failed: TypeError: Path must be a string. Received undefined
at assertPath (path.js:7:11)
at Object.dirname (path.js:1326:5)
at ensureTypeScriptInstance (/Users/vicensfayos/Projects/angular2-abc/node_modules/ts-loader/index.js:156:103)
at Object.loader (/Users/vicensfayos/Projects/angular2-abc/node_modules/ts-loader/index.js:403:14)
So my question is: what I am missing with symlinks when I "distribute" the source code in another folder out of the project folder itself?
My guess is about configure properly resolving object in webpack https://webpack.github.io/docs/resolving.html to override the node.js loading node_modules algorithm https://nodejs.org/api/modules.html#modules_loading_from_node_modules_folders but not luck.
Hopefully somebody can point me in some direction.
I found the answer.
My guess was right. it was about how nodejs resolve the dependencies. https://nodejs.org/api/modules.html#modules_loading_from_node_modules_folders
The symlinked code is trying to find the dependencies moving up all the way failing until it finds node_module. But nothing is there. node_module is in the parent project.
Therefore the solution is create another symlink from the symlinked code to the node_modules folder of the parent project to resolve the dependencies.
I have a similar setup but decided to add a path to my tsconfig.json in my main app:
"paths": {
"*": ["*", "node_modules/*"]
}
All the modules required by the source code in the shared symlinked folders are in the main app's node_modules folder. This tells the compiler to look in the main app's node_modules folder before trying to find a node_modules folder further up the tree.
Related
Please, help me understand, how to deal with such issue:
I use vue-cli and I want to build in dev mode some js file and then be able to access it by url like: http://localhost:8080/my-file.js
But by default, I can't do it in such way. As I understand, I have to override devServer option?
You can put the JS files you want to include in a root folder called /public/ and when yarn build runs (or npm build if you're using that) it will output them exactly as they are in public to the dist folder for reference like you're looking for.
Note that the public folder needs to be at the same level as your src folder - not inside the src folder.
Source: https://cli.vuejs.org/guide/html-and-static-assets.html#preload
In my project, I have an /src folder that contains .ts files and I setup tsconfig.json to compile those in a folder called /dist into .js and source map .js.map.
Now I run the code using the commande node /dist/whatever.js
But Let's say there in a error. The error logs maps to the compiled .js files.
How to make it map to the original .ts file ? I assume this is possible because that's the use of source map.
Happened to see this question. I didn't really use IntelliJ, but I have been using source-map-support to do the trick. You could either programmtically add import 'source-map-support/register';, or invoke node CLI node -r source-map-support/register compiled.js. Hope that helps.
I see you are using IntelliJ. You can exclude directories so they will not be indexed.
I'm new into webpack, and I'm having an issue trying to resolve a subdependency.
I'm importing a dependency that is trying to require a module from a specific folder (not the node_modules) (let's call it subdependency). That folder contains two files:
subdependency/package.json
subdependency/build/Release/addon.node
subdependency/lib/src/index.js (this index.js requires the addon.node)
I'm using webpack, and when importing my dependency it was not able to find subdependency.
The subdependency is there but it was not accessible. I added a loader for loading .node files https://www.npmjs.com/package/native-ext-loader and it was still not working; trying to identify what was happening I modified in my build the require path from ./subdependency to ./subdependency/build/Release/addon.node and the file was accessible (so I guess the native ext loader is working fine, but it's not loading other files like the index.js).
I think the problem is that webpack is not able to understand that ./subpdendency is a module, or that I'm not loading it correctly.
Any suggestion or idea is welcome!
I resolved the issue by forking the dependency and switching from node-pre-gyp to prebuildify, since node-pre-gyp doesn't works fine with webpack.
Issue
Would any Webpack config experts out there be able to tell me why I can't extract my css into the dist folder when running npm run build?
Repo is here: https://github.com/damodog/webpack4-boilerplate
Further info
To summarise, I've been working through the Webpack Guide docs and everything was going well. js and css was getting injected into my index.html file via <link> and <script> tags respectively. I've installed various loaders, plugins etc and split my configs out into common (shared), dev and prod files (as per the docs) and life was good.
I happened to make some tweaks which included looking at code splitting dynamic imports, adding aliases for paths, moving js into js folder etc and noticed when I ran a build npm run build all of a sudden my css wasn't getting added to the dist folder. I reverted my trial changes for the dynamic import stuff and tried reverting the other changes but am still getting the same issue. Annoyingly I hadn't added git at this point so didn't have a clear picture of the 'tweaks' I'd made to locate what I'd changed.
What happens
When I run my watch task npm start the styles.scss file (imported into the main index.js file) get's compiled into css and the resulting app.css file gets injected into the index.html page when viewed in my local host. All gravy.
<link href="css/app.css" rel="stylesheet">
When I run npm run build the css file should get copied over dist folder, a hash id should get added and the css should be minified. This was working (like I said above) and I could see the css file in the build steps (see first Asset below. Btw disregard the difference in js bundled files here compared to the next screenshot. This was when I was playing with code splitting).
Now when I run this the css isn't bundled up (see below).
I think it could be something to do with mini-css-extract-plugin but I've configured this as per the docs using the advanced configuration example (I've split their example out which is in one config file as I have separate config files for dev and prod).
I literally cannot see why this is happening.
Help me SO readers. You're my only help...
I cloned your repo and experimented with it. In your package.json, you've set: sideEffects: false. This causes the imported stylesheets to be lost in the process of tree shaking. This is described in the docs:
A "side effect" is defined as code that performs a special behavior
when imported, other than exposing one or more exports. An example of
this are polyfills, which affect the global scope and usually do not
provide an export.
and
Note that any imported file is subject to tree shaking. This means if
you use something like css-loader in your project and import a CSS
file, it needs to be added to the side effect list so it will not be
unintentionally dropped in production mode
So change your side effects in package.json to "sideEffects: ["./src/scss/styles.scss"] and it will be output to the destination folder when in production mode.
While "requiring" non-local NodeJS modules, what is the meaning of slash in module name?
Example:
from ShellJS npm module's github page (link: https://github.com/shelljs/shelljs#javascript)
require('shelljs/global');
require('shelljs/make');
Upon looking at the directory structure of ShellJS github project, I notice that both global.js and make.js are both at same level as shell.js which is the main entry point of the module as per its package.json. So what does the slash mean in the package name and how, in above example, is the path to "global" and "make" resolved?
Slash (as it primary use), is just simply used for file paths.
require('shelljs/global') will load script of global.js file.
require('shelljs/make') will load script of make.js file.
However, require('shelljs') will load script of shell.js.
Why? Let's look at the content of package.json: It's "main": "./shell.js" that makes the magic.