From my point of view, this approach will help you to write cleaner code. Also, it will help to maintain the project. For instance, moving a file from the current directory to another will cause fewer problems, because every file uses an absolute path instead of a relative one. Last but not least, it helps you during development.

alias: { '@': path.resolve(__dirname, 'src'),}

Use this to load modules whose location is specified in the paths section of tsconfig.json when using webpack. This package provides the functionality of the tsconfig-paths package but as a webpack plug-in. Using this plugin means that you should no longer need to add alias entries in your webpack.config.js which correspond to the paths entries in your tsconfig.json. This plugin creates those alias entries for you, so you don't have to!

The declarations you make in the tsconfig.json are re-stated in the webpack.config.js. Who wants to maintain two sets of code where one would do? Not me.

Let's not get over-excited. Actually, we're only part-way there; you can compile this code with the TypeScript compiler.... But is that enough?I bundle my TypeScript with ts-loader and webpack. If I try and use my new exciting import statement above with my build system then disappointment is in my future. webpack will be all like "import whuuuuuuuut?"You see, webpack doesn't know what we told the TypeScript compiler in the tsconfig.json.

config: path.resolve(__dirname, '../config'), vue: 'vue/dist/vue.js', src: path.resolve(__dirname, '../src'), store: path.resolve(__dirname, '../src/store'), assets: path.resolve(__dirname, '../src/assets'), components: path.resolve(__dirname, '../src/components'), '@': path.resolve(__dirname, '../src'),

alias: { _self: path.join(__dirname, 'src/web'), _shared: path.join(__dirname, 'src/shared'), _components: path.join(__dirname, 'src/web/components'), _helpers: path.join(__dirname, 'src/web/helpers'), _layers: path.join(__dirname, 'src/web/layers'), _mutations: path.join(__dirname, 'src/web/mutations'), _routes: path.join(__dirname, 'src/web/routes') }

alias: { '@components': path.join(srcDir, 'components'), '@modules': path.join(srcDir, 'modules'), '@store': path.join(srcDir, 'store') }

Aliases are absolute nonsense for resolving imports. If you don't want to type ../ consider using something like path.resolve(__dirname, '../src') so you can do import Stuff from 'client/components/stuff'; // relative to root of project instead of: import Stuff from 'COMPONENTS/stuff'; // this is dumb

alias: { '@shared': path.dirname(require.resolve('app')), '~': path.join(fs.realpathSync(process.cwd()), 'app'), },

In this example, @shared is the package, ~ is the project. I wouldn't do it this way in the future, but I know this configuration works.

alias: { Library: path.resolve(__dirname, "root/library/"), Single: path.resolve(__dirname, "root/test.js"), },

alias: { Single$: path.resolve(__dirname, "root/test.js"), },

The webpack templates now have resolve.alias in their config

The resolve.alias option is used to make sure that only one copy of the Svelte runtime is bundled in the app, even if you are npm linking in dependencies with their own copy of the svelte package. Having multiple copies of the internal scheduler in an app, besides being inefficient, can also cause various problems.

formvalidation: path.resolve

import luhn from 'formvalidation/algorithms/luhn';

You can then ensure that only one instance of angular is loaded from your main module by adding an alias

Svelte needs to be deduped. Adding a Webpack alias for resolution of the module appears to be a temporary workaround:

resolve.alias