merkle-open / frontend-defaults Goto Github PK

Using babel >=7 we have to use the scoped names @babel/env or @babel/preset-env instead of env
"presets": [
"@babel/preset-env"
]

and even better:
It would make sense to use babel.config.js instead of .babelrc. This allows a more flexible configuration.

Example babel.config.js:

module.exports = {
	presets: [
		[
			require.resolve('@babel/preset-env'),
			{ useBuiltIns: 'entry' },
		]
	],
	plugins: [...],
};

Our usage recommendation for prettier-config with lint-staged does not work anymore with prettier 1.15.3.
In 1.15.3 they changed the status code to "0" in any case using the options --write and --list-different together. This leads to the fact that the commit now works despite errors. Another commit must therefore be appended. (discussion)

The solution worked perfect before ;-)
I'm unsure what we should do now.

I don't really like these ideas:

• downgrade to prettier 1.15.2
• adding git add to "lint-staged" config
• using --list-different only will prevent the commit, but won't give us meaningful feedback

Any ideas?

Have you considered to add the stylelint plugin stylelint-scss?

It allows to disallow scss code like the following:

.class {
  &-union {
//↑
// This type usage of `&`
  }
}

https://github.com/kristerkari/stylelint-scss/blob/master/src/rules/selector-no-union-class-name/README.md

The jest snapshot tests aren't windows compatible.

example:

   ".babelrc": {
            "override": false,
    -       "data": "{\\n\\t\\"presets\\": [\\n\\t  \\"env\\"\\n\\t]\\n}"
    +       "data": "{\\r\\n\\t\\"presets\\": [\\r\\n\\t  \\"env\\"\\r\\n\\t]\\r\\n}"
          }
      }

Because TypeScript has been available in version 4 for some time, we should also make the configuration compatible.

Pretty-quick gets called without additional parameters package.json, so all staged files will be validated, even if they are not supposed to be.
Either there should be the additional pattern parameter or even better since lint-staged is used just use prettier --write as it is done in the script section of package.json

We are using the following rule configuration in our stylelint.config.js in our project:

module.exports = {
	'extends': '@namics/stylelint-config',
        'rules': {
            'at-rule-no-unknown': null, // at-rule-no-unknown of stylelint can't be used for SASS
	    'scss/at-rule-no-unknown': true, // instead, scss-stylelint's rule has to be used
        '
};

This is per documentation of stylelint-scss: https://github.com/kristerkari/stylelint-scss#-rule

at-rule-no-unknown: Disallow unknown at-rules. Should be used instead of stylelint's at-rule-no-unknown.

https://github.com/kristerkari/stylelint-scss/blob/master/src/rules/at-rule-no-unknown/README.md

We have great linting presets which guide developers into the right direction and prevent human errors.

Unfortunately the amount of "disable-next-line" comments increased a lot in many projects where linters are used.

For me that is a symptom that something about our linters does not work the way we intended it.
In my opinion we should use "disable-next-line" similar to complex scss mixins and loops.
It's fine for abstract utils but should not be used in our day to day work.

I would like to discuss one lint rule as an example but it might also be true for other lint rules.
Many projects contain the following code:

console.log('debug', valueX); // eslint-disable-line

So if this rule has to be disabled so many times why do we have it in our defaults anyway?
The idea behind this rule is that we don't want to have console.log statements in our merged code.

In our projects we have the following four quality gates:

1. ide & dev build
2. precommit
3. git server received push
4. manual code review

For me it seems like that linting for console.log in step 1 causes issues for most developers so they disable it while fiddeling around with their code to find a good way to implement a feature or to debug a bug.
However disabling the linting rule moves it to step 4 which is a manual task of a second person.

What do you think about moving it to step 2 or step 3?

We might achieve that with two configs:

.eslintrc.json (for step 1) without the console.log rule or console.log as warning
.eslintrc.strict.json (for step 2 or step 3) which extends .eslintrc.json and adds the console.log rule as error

The default parser is set to typescript without any overwrite for md files.

https://github.com/namics/frontend-defaults/blob/cc10f74c37444cafb0d27c6c206be5b375bc0df6/codequality/prettier/index.js#L11

Unfortunately this causes the following error:

SyntaxError: Invalid character. (1:1)
> 1 | # Hello World
    | ^
  2 | 
  3 | Lorem ipsum
  4 | 
at e (node_modules/prettier/parser-typescript.js:1:329)

https://github.com/matzkoh/prettier-plugin-packagejson
https://github.com/cameronhunter/prettier-package-json
https://github.com/henrikjoreteg/fixpack#fixpack (not prettier)

Reproduce:

Execute the following:

npx @namics/frontend-defaults-cli@alpha my-project

And afterwards:

cd my-project && npm start

Hey there,

we are using @namics/stylelint-config in our project at Namics and noticed npm is logging a warning upon executing npm install:

npm WARN [email protected] requires a peer of stylelint@^8.0.0 || ^9.0.0 || ^10.0.0 || ^11.0.0 || ^12.0.0 but none is installed. You must install peer dependencies yourself.

This happens because @namics/stylelint-config depends on stylelint-scss 3.13.0 which does not support the latest stylelint yet.

Would it be possible to update the dependency to the latest version of stylelint-scss?

Thanks :)