Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Consider adding an alias for the generated frontend assets

See original GitHub issue

Refactoring a frontend project could be easier if we aliased the generated folder with webpack https://webpack.js.org/configuration/resolve/

That way, you could write import Company from 'Generated/com/vaadin/tutorial/crm/backend/entity/Company';

instead of import Company from '../../../../../generated/com/vaadin/tutorial/crm/backend/entity/Company';

Which would also not break if you move the file around.

Issue Analytics

State:
Created 3 years ago
Reactions:3
Comments:9 (9 by maintainers)

Top GitHub Comments

1reaction

platoshacommented, Jan 27, 2021

Tried both the path aliases and the package symlink approaches. The auto-complete and auto-import behaviour in VSCode and IntelliJ IDEA is the same between both approaches, so “IDE support” refers to both of them below.

The approach	Example auto-import path	IDE support	Notes
No alias (current behaviour)	`../../generated/MyEndpoint`	✅	Traversing levels of hierarchy, as outlined in this issue.
Package alias (as suggested in #7758)	`@vaadin/generated/MyEndpoint`	❌	Auto-import refers to the relative path instead, unless `generated` is moved out of `frontend`. Requires FS symlink.
Prefixed alias for the generated directory (as in the issue description)	`Generated/MyEndpoint`	✅
Prefixed frontend directory alias	`Frontend/generated/MyEndpoint`	✅	Also allows simple references for other `frontend` exports.
Bare root to frontend directory alias	`/generated/MyEndpoint`	✅	See above.

The package alias approach has clear downsides here.

I’d personally prefer aliasing the Frontend:

Simple references for other frontend things, e. g., import { router } from 'Frontend/index';
Helps to avoid maintaining multiple specific aliases
The webpack documentation also has examples using capital case aliases. This is probably to minimise the risk of confusion with npm package names, which must start with a lowercase letter or @scope-name.
We already have the Frontend alias in generated webpack config for internal use. Adding it to tsconfig.json while implementing this issue would also align aliases in both places, which is nice to have.

0reactions

vlukashovcommented, Feb 2, 2021

This is probably a late comment, but just noticed today that NuxtJS is using ~ as the alias to the source root: https://nuxtjs.org/docs/2.x/directory-structure/assets

Top Results From Across the Web

Consider adding an alias for the generated frontend assets

Consider adding an alias for the generated frontend assets. ... import Company from 'Generated/com/vaadin/tutorial/crm/backend/entity/Company';. instead of

You can manage aliases for FrontEnd Workflow in one place

Now with the above project config, you can add aliases to your webpack in webpack.config.js as: const aliases = require('alias-hq') ...

How to resolve aliases in Storybook? - Stack Overflow

Just add this in your .storybook/main.js const path = require('path'); module.exports = { "stories": [ "../components/**/*.stories.mdx", ".

Robust Frontend Development With Aliases | by Benjamin Todts

To make it understand webpack's aliases, you can add so-called resolvers to this plugin. We will use the eslint-import-resolver-webpack ...

Using aliases in GraphQL - LogRocket Blog

Keep in mind that with each renaming, you'll need to propagate the new name everywhere in your code. Before adding an alias, you...