Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace node-sass with sass (naïve attempt) #29

Closed
wants to merge 2 commits into from

Conversation

SimonAlling
Copy link
Owner

@SimonAlling SimonAlling added the dependencies Pull requests that update a dependency file label Nov 8, 2020
@SimonAlling SimonAlling changed the title Replace node-sass with sass Replace node-sass with sass (naïve attempt) Apr 4, 2021
@SimonAlling
Copy link
Owner Author

Superseded by #45.

@SimonAlling SimonAlling closed this Apr 4, 2021
SimonAlling added a commit that referenced this pull request Apr 21, 2021
[Node Sass has been deprecated in favor of Dart Sass.][libsass]

For this project in particular, Node Sass is the cause of lengthy
compilations when running `npm ci`, annoying GYP errors and [multiple
security vulnerabilities][snyk].

[libsass]: https://sass-lang.com/blog/libsass-is-deprecated
[snyk]: https://snyk.io/test/npm/userscripter/1.4.0

When we first tried to migrate in #29, it turned out that ["just
[replacing] `node-sass` in [our] `package.json` file with
`sass`"][migrate] didn't work, because doing so broke our mechanism for
accessing JavaScript values from within SCSS (i.e. `getGlobal`). For
example, tests would fail like so:

    can expose data to SASS

    expect(received).toMatchInlineSnapshot(snapshot)

    Snapshot name: `can expose data to SASS 1`

    Snapshot: SassNumber {}
    Received: undefined

[migrate]: https://sass-lang.com/blog/libsass-is-deprecated#how-do-i-migrate

We tried to fix this by upgrading packages (e.g. `node-sass-utils` to
version 1.1.3 and `sass-loader` to 11.0.1), but that would cause build
errors in dependent userscripts like [Better SweClockers][bsc] (e.g.
`SassError: Only 0 arguments allowed, but 1 was passed.` at `getGlobal`
call sites). As far as we could tell, we wouldn't be able to fix that by
upgrading dependencies, at least not without forcing dependent projects
to upgrade to webpack 5.

[bsc]: https://github.com/simonalling/better-sweclockers

The solution we finally arrived at was to adapt `getGlobalFrom` to work
with `sass` instead of `node-sass` and, in the webpack config we
generate for dependent projects, make sure the parameters of the SASS
variable getter are properly Dart Sass-encoded – conceptually:

```diff
 sassOptions: {
     functions: {
-        ["getGlobal"]: getGlobal,
+        ["getGlobal($x0)"]: getGlobal,
     },
 },
```

We decided that this is _not_ a breaking change, because although
dependent projects using the SASS variable getter in JavaScript (i.e.
not in SCSS) may break, we don't consider that a supported use case (and
we don't know of any such projects). Dependent projects using
`getGlobal` as intended (i.e. in SCSS) shouldn't be affected. In order
to confirm this, we have built, tested and used Better SweClockers (as
of [`f01d834`][bsc-commit]) based on this PR without any issues.

[bsc-commit]: SimonAlling/better-sweclockers@f01d834

Co-authored-by: Simon Alling <alling.simon@gmail.com>
@SimonAlling SimonAlling deleted the replace-node-sass branch April 22, 2021 19:00
SimonAlling added a commit that referenced this pull request May 3, 2021
[Node Sass has been deprecated in favor of Dart Sass.][libsass]

For this project in particular, Node Sass is the cause of lengthy
compilations when running `npm ci`, annoying GYP errors and [multiple
security vulnerabilities][snyk].

[libsass]: https://sass-lang.com/blog/libsass-is-deprecated
[snyk]: https://snyk.io/test/npm/userscripter/1.4.0

When we first tried to migrate in #29, it turned out that ["just
[replacing] `node-sass` in [our] `package.json` file with
`sass`"][migrate] didn't work, because doing so broke our mechanism for
accessing JavaScript values from within SCSS (i.e. `getGlobal`). For
example, tests would fail like so:

    can expose data to SASS

    expect(received).toMatchInlineSnapshot(snapshot)

    Snapshot name: `can expose data to SASS 1`

    Snapshot: SassNumber {}
    Received: undefined

[migrate]: https://sass-lang.com/blog/libsass-is-deprecated#how-do-i-migrate

We tried to fix this by upgrading packages (e.g. `node-sass-utils` to
version 1.1.3 and `sass-loader` to 11.0.1), but that would cause build
errors in dependent userscripts like [Better SweClockers][bsc] (e.g.
`SassError: Only 0 arguments allowed, but 1 was passed.` at `getGlobal`
call sites). As far as we could tell, we wouldn't be able to fix that by
upgrading dependencies, at least not without forcing dependent projects
to upgrade to webpack 5.

[bsc]: https://github.com/simonalling/better-sweclockers

The solution we finally arrived at was to adapt `getGlobalFrom` to work
with `sass` instead of `node-sass` and, in the webpack config we
generate for dependent projects, make sure the parameters of the SASS
variable getter are properly Dart Sass-encoded – conceptually:

```diff
 sassOptions: {
     functions: {
-        ["getGlobal"]: getGlobal,
+        ["getGlobal($x0)"]: getGlobal,
     },
 },
```

We decided that this is _not_ a breaking change, because although
dependent projects using the SASS variable getter in JavaScript (i.e.
not in SCSS) may break, we don't consider that a supported use case (and
we don't know of any such projects). Dependent projects using
`getGlobal` as intended (i.e. in SCSS) shouldn't be affected. In order
to confirm this, we have built, tested and used Better SweClockers (as
of [`f01d834`][bsc-commit]) based on this PR without any issues.

[bsc-commit]: SimonAlling/better-sweclockers@f01d834

Co-authored-by: Simon Alling <alling.simon@gmail.com>
SimonAlling added a commit that referenced this pull request Jun 4, 2021
[Node Sass has been deprecated in favor of Dart Sass.][libsass]

For this project in particular, Node Sass is the cause of lengthy
compilations when running `npm ci`, annoying GYP errors and [multiple
security vulnerabilities][snyk].

[libsass]: https://sass-lang.com/blog/libsass-is-deprecated
[snyk]: https://snyk.io/test/npm/userscripter/1.4.0

When we first tried to migrate in #29, it turned out that ["just
[replacing] `node-sass` in [our] `package.json` file with
`sass`"][migrate] didn't work, because doing so broke our mechanism for
accessing JavaScript values from within SCSS (i.e. `getGlobal`). For
example, tests would fail like so:

    can expose data to SASS

    expect(received).toMatchInlineSnapshot(snapshot)

    Snapshot name: `can expose data to SASS 1`

    Snapshot: SassNumber {}
    Received: undefined

[migrate]: https://sass-lang.com/blog/libsass-is-deprecated#how-do-i-migrate

We tried to fix this by upgrading packages (e.g. `node-sass-utils` to
version 1.1.3 and `sass-loader` to 11.0.1), but that would cause build
errors in dependent userscripts like [Better SweClockers][bsc] (e.g.
`SassError: Only 0 arguments allowed, but 1 was passed.` at `getGlobal`
call sites). As far as we could tell, we wouldn't be able to fix that by
upgrading dependencies, at least not without forcing dependent projects
to upgrade to webpack 5.

[bsc]: https://github.com/simonalling/better-sweclockers

The solution we finally arrived at was to adapt `getGlobalFrom` to work
with `sass` instead of `node-sass` and, in the webpack config we
generate for dependent projects, make sure the parameters of the SASS
variable getter are properly Dart Sass-encoded – conceptually:

```diff
 sassOptions: {
     functions: {
-        ["getGlobal"]: getGlobal,
+        ["getGlobal($x0)"]: getGlobal,
     },
 },
```

We decided that this is _not_ a breaking change, because although
dependent projects using the SASS variable getter in JavaScript (i.e.
not in SCSS) may break, we don't consider that a supported use case (and
we don't know of any such projects). Dependent projects using
`getGlobal` as intended (i.e. in SCSS) shouldn't be affected. In order
to confirm this, we have built, tested and used Better SweClockers (as
of [`f01d834`][bsc-commit]) based on this PR without any issues.

[bsc-commit]: SimonAlling/better-sweclockers@f01d834

Co-authored-by: Simon Alling <alling.simon@gmail.com>

Co-authored-by: Andrew Valleteau <avallete@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant