teachiq / eslint-config Goto Github PK

Ts linting config needs adjusting.
Consider to make different installations depending on project type

I followed the guide in the README and had to add two settings to .vscode/settings.json

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

Though, when saving it looks like it first formats correctly (with standard-js) but then adds semi-colons (probably air-bnb). Am I missing some settings?

This discussion is preventive, not triggered by anything specific.

I noticed this, and a few other, repositories are public. There is of course nothing secret here but it's very easy to forget about the publicity during discussions and issue-comments, so we have to be careful about what we mention, to not add any personal data, details of ongoing projects etc.

The pros of keeping it public is free access to CI tools and similar services, for package publishing, and possibly as "marketing". I absolutely think we can keep it public, but we should have a short internal discussion to ensure everyone is aware of this.

Today we build each util as a separate module in order to guarantee that it's possible to import only the utils that we need without relying on opaque tree-shaking processes in build tools.

In order to get nice imports like  import x from @Teachiq/utils/x as well as avoid clutter in the root directory of the project, we're forced to do the following since npm (package.json) doesn't have a great interface for structure the package contents:

1. build each separate module into the libdirectory
2. move the modules to the root directory of the project
3. run npm publish, where package.json is set to point at each module at the root (see the files option)
4. move the modules back to lib to avoid clutter in the root directory

This requires a whole lot of setting up if a new type of utility module is to be added, which may be a large time sink.

My suggestions to solve this:

1. Let the root directory be cluttered and just build package directly there
2. Make a build script that magically handles building and publishing modules in the source directory
3. Simplify the project structure and rely on build-tool treeshaking