Where are eslint-import-resolver-aliases resolved from? - javascript

On the npm page of eslint-import-resolver-alias is following piece of code:
module.exports = {
  settings: {
    'import/resolver': {
      alias: {
        map: [
          ['babel-polyfill', 'babel-polyfill/dist/polyfill.min.js'],
          ['helper', './utils/helper'],
          ['material-ui/DatePicker', '../custom/DatePicker'],
          ['material-ui', 'material-ui-ie10']
        ],
        extensions: ['.ts', '.js', '.jsx', '.json']
      }
    }
  }
};
But I have a problem finding out where are the paths in map getting resolved from.
My current project is of this structure:
project_root/
├─ modules/
│ ├─ client/
│ │ ├─ node_modules/
│ │ ├─ src/
│ │ │ ├─ components/
│ │ ├─ README.md
│ │ ├─ tsconfig.json
│ │ ├─ .eslintrc.js
│ │ ├─ package.json
I want to make an alias to components folder. So should it be:
['#components', path.resolve(__dirname, './src/components')]
// OR
['#components', path.resolve(__dirname, 'components')]
// OR
['#components', './src/components']
// ...
Nothing I tried seemed to work, but it's hard to further debug as I don't know, if the paths may not be correct in the first place.
So I need to know if the paths are resolved from project_root location of .eslintrc.js or src or something else.
Also please consider that it needs to work with VS Code's Eslint server when you open the project in project_root.

Related

Javascript clean architecture question: is there a way to enforce dependency restrictions on a file or directory, and write a Jest-ful test for it?

For example, let's say we have the following "clean architecture" project structure:
.
│ README.md
│ package.json
│ ...
│
└─── src
│ │ app.js
│ │ app.test.js
│ │ ...
│ │
│ └─── entities
│ │ │ foo.js
│ │ │ foo.test.js
│ │ │ bar.js
│ │ │ ...
│ │
│ └─── useCases
│ │ │ useFooAndBarToBaz.js
│ │ │ ...
│ │
...
How could a test be written to enforce the architectural concept that Entities should not have outward dependencies? IE: no file in the /entities directory should import and use any classes, functions etc found in another directory (/useCases directory in this example).
If possible, I would like to use Jest to write the test(s) (ideally in app.test.js to test the whole /entities directory, but if that's not possible then in foo.test.js to test the content of foo.js, etc etc), but I don't see anything glaringly obvious in the Jest docs about testing file imports.
There may be alternative ways to go about this (can Jest be used in combination with a bash script to walk the directories or something?), so I'm open to ideas.

Incorrect images path in public folder

This is structure of my (vanilla js) app:
├─ assets/
│ ├─images
│ │ ├─first/
│ │ │ ├image1.png
│ │ │ ├image2.png
│ │ │ ├... etc
│ │ ├─second/
│ │ ├─third/
├─ node_modules/
├─ public/
│ ├─ assets/
│ ├─ index.html
├─ index.html
├─ main.js
├─ style.scss
├─ package.json
Everything works fine untill I run build, then path of my images is gone and every single image is in same publics direction:
├─ dist/
│ ├─ assets/
│ │ ├first.jpg
│ │ ├second.jpg
│ ├─ index.html
so paths from my dev environment are incorrect in public. Is there a possibility to keep my dev path structure after build?
Ant another issue - for some reason, on build project includes slash to script and styles, so my public html files have no scripts and styles, I have to remove it by myself.
Here is vite config file:
export default {
build: {
outDir: 'public',
rollupOptions: {
input: {
main: './index.html',
about: './about.html',
contact: './contact.html',
design: './design.html',
innovation: './innovation.html',
media: './media.html',
spaceline: './spaceline.html',
ucsl88: './uc-sl-88.html',
ucsl120: './uc-sl-120.html',
ucsl150: './uc-sl-150.html',
}
}
}
}
Thanks

Run multiple instance of a same script in nodeJS

I'm working on a website offering scraping with Puppeteer on NodeJS, so I decided to make a website using NodeJS and Express.
The scraping script must therefore be executed once a form has been completed.
The script must therefore be executed again for each new request without canceling the previous one. Hence I don't know how much script will be loaded in advance.
I think PM2 can be a good idea but, I'm not sure if it meets my needs.
Or I could use Node.js Cluster, this would allow me to create a fork for each filled form.
Here is the tree structure of my project:
my-app/
├─ bin/
│ ├─ www
├─ node_modules/
├─ public/
│ ├─ images/
│ ├─ javascript/
│ │ ├─ scrapper.js
│ │ ├─ script.js
│ ├─ stylesheets/
├─ routes/
│ ├─ index.js
├─ views/
│ ├─ error.pug
│ ├─ index.pug
│ ├─ layout.pug
├─ app.json
├─ package-lock.json
├─ package.json

How does an import from node_modules really work in ReactJS?

I installed react-vis via npm install react-vis
and its possible to write
import { XYPlot, LineSeries } from 'react-vis';
I want to know how the systems knows where XYPlot and LineSeries are? I looked in the node_modules directory and there is no index.js.
The structure of the react-vis directory is the following
my-app/
├─ node_modules/
│ ├─ react-vis/
│ │ ├─ dist/
│ │ ├─ es/
│ │ ├─ CHANGELOG.md
│ │ ├─ LICENSE
│ │ ├─ package.json
│ │ ├─ README.md
How does this work?
I researched and for example this does not helped me: Where { component } from 'react' is located when we are importing ReactJS?
Edit
I think it looks in the package.json that is inside the react-vis directory. There are two entries that look interesting. "name": "dist" and "module": "es". I think that i have to look inside the dist directory. Inside the dist directory, there is an index.js file. I open this file and on line 318 it says exports.XYPlot = _xyPlot2.default;
In the es folder inside the index.js there is on line 98 this: export { _XYPlot as XYPlot }; I don't know if this is important.

Should I copy files from bower_components of reference them there?

After installing BackboneJS, jQuery etc I have a very large bower_components directory.
├───.idea
│ ├───runConfigurations
│ └───scopes
└───app
├───bower_components
│ ├───backbone
│ ├───jquery
│ │ ├───dist
│ │ └───src
│ │ ├───ajax
│ │ │ └───var
│ │ ├───attributes
│ │ ├───core
│ │ │ └───var
│ │ ├───css
│ │ │ └───var
│ │ ├───data
│ │ │ └───var
│ │ ├───effects
│ │ ├───event
│ │ ├───exports
│ │ ├───manipulation
│ │ │ └───var
│ │ ├───queue
│ │ ├───sizzle
│ │ │ ├───dist
│ │ │ └───test
│ │ │ ├───data
│ │ │ └───unit
│ │ ├───traversing
│ │ │ └───var
│ │ └───var
│ └───underscore
├───css
└───js
What is best practice to reference these? e.g directly, Grunt task to copy bits to the main app, or put the bower_componects inside the ~/app directory?
Don't copy them over to your app - that completely defies the intent of a package manager like Bower! By doing so, you'd take control over these files away from your package manager - and then you're left in the same state as before, manually having to copy over files every time with an update of these dependencies.
Just reference the files inside the bower_components/ directory directly (in your HTML, most likely). If you don't like that location or name, you can have bower put your components some place else, see .bowerrc doc: http://bower.io/docs/config/
I can think of a use for only using specific files from your bower_components directory - but only at build time:
If you write a grunt task that runs only at deploy time and strips away all unused files from the bower_components directory, that of course makes sense and does not go against the idea of a package manager, because it only happens on each deploy, a point when the package manager has no responsibilities.
The only problem you might get with this approach is if you have it end up copying files over to a different directory - because then you'd have to change the references to all files from bower_components before deploying, too. The easy solution is to not duplicate files, but instead, only delete the ones you don't need.
Just leave them in bower_components and refer proper files inside your index.html file. You can do this manually, or use tools like grunt wiredep to do this for you automatically.

Categories