linaria/stylelint-config silently fails and thus doesn't work

[Hotell]

bug

What is the current behavior?

apparently stylelint-config preprocessor traverses all module dependencies(imports) and on error silently fails, which results in false outcomes -> no styling errors

here is the culprit of muting processing errors
https://github.com/callstack/linaria/blob/693919448f/src/stylelint/preprocessor.js#L21

when monorepo dependencies are bundled and present on the disk, it will work

This is bad DX as usually apps/libs are bundled in memory mode (in my case webpack-dev-server), so those module imports are not physically present on disk.

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.

// stylelint.config.js
const config = {
  extends: ['stylelint-config-recommended', 'linaria/stylelint-config'],
};

stylelint packages/**/*.{ts,tsx}

import React from 'react';
import { css } from 'linaria';

const someStyle = css`
  display: block;
  background-color: #333;
  color: pink !important;
  width: 200;
  widhzzz: 300;
`;

function App() {
  return <div className={someStyles} />;
}

What is the expected behavior?

So I see here 2 issues that need to be solved:

• don't swallow errors (properly emit occured error)
• make lint work without traversing absolute module imports ( stylelint-processor-styled-components works like that )

Please provide your exact Babel configuration and mention your Linaria, Node, Yarn/npm version and operating system.

├─ [email protected]
└─ [email protected]

[satya164]

This is bad DX as usually apps/libs are bundled in memory mode (in my case webpack-dev-server), so those module imports are not physically present on disk.

Can you clarify what it means? I know the output files are written to memory fs for dev server, but why would the input modules be in memory fs?

don't swallow errors (properly emit occured error)

Yea we'll do this

make lint work without traversing absolute module imports ( stylelint-processor-styled-components works like that )

The styled components preprocessor is very limited (e.g. it can't know the type of certain interpolations and you have to add comments to tell it). Linaria's preprocessor evaluates the modules and is able to provide better linting as a result.

[Hotell]

This is bad DX as usually apps/libs are bundled in memory mode (in my case webpack-dev-server), so those module imports are not physically present on disk.

Can you clarify what it means? I know the output files are written to memory fs for dev server, but why would the input modules be in memory fs?

I've created image, as I think it describes the issue better.

[satya164]

Hmm we only lint the source files, don't care about generated files (like in dist)

[Hotell]

I know you are (which makes sense ofc), but if those generated are not present ,lint throws error (babel parse error).

[satya164]

but if those generated are not present ,lint throws error (babel parse error)

that shouldn't happen and I'm not sure why it happens. will be great if you can create a repro and I'll investigate it

[satya164]

the errors should no longer be ignored #339

[satya164]

I'm wondering if the main field in package.json in your folders point to dist. That might explain the error.

Also, are you using webpack aliases? That won't work with the stylelint processor because it doesn't know about webpack. Using https://github.com/tleunen/babel-plugin-module-resolver will work for both. However I'm not sure why having dist will make it work.

[Hotell]

I'm wondering if the main field in package.json in your folders point to dist. That might explain the error.

Ofc they are. I thought it's obvious LOL.

Also, are you using webpack aliases?

Yes, aliases are used for monorepo packages so they don't have to be present physically rather then build all together in memory.

That won't work with the stylelint processor because it doesn't know about webpack

I know that stylelint processor doesn't know about anything webpack specific. Why should it anyways. That's what I was trying to explain. Styled-components-stylelint works without any further Babel configs, linaria is not.

😀

[satya164]

Ofc they are. I thought it's obvious LOL.

It's not obvious because webpack build is working without them. Also Linaria is able to evaluate these files inside webpack, so they must be on fs. (We use webpack's resolution, but still if the files aren't there, it wouldn't work). The stylelint processor uses the same code as the webpack loader (only the resolution is different in webpack).

Yes, aliases are used for monorepo packages so they don't have to be present physically rather then build all together in memory.

How are the dist/ files written to memory fs? Or do the aliases point at src/? I know webpack dev server writes output files to memory fs, but in your case seems you are saying that the input modules live in memory fs.

It'll be great if you can share a small demo so I can understand what's happening.

Styled-components-stylelint works without any further Babel configs, linaria is not.

Yeah, but SC's preprocessor is very limited as I mentioned. You won't get the same level of linting from SC as this plugin because of evaluation. Though the linter isn't doing anything the loader doesn't do already. Only the webpack resolution can be different. In which case babel-plugin-module-resolver is better option (tools like Jest etc. also won't work without configuration if webpack's resolution is different).