Compilation Error

[romleinster]

When I try to compile with
sass main.scss theme.css
I get this error:
Error: expected selector. ╷ 173 │ 20%:before, │ ^ ╵ ..\base\_mixins.scss 173:3 loopingProgressBar() ..\base\widgets\_widget.scss 501:3 widget() ..\base\widgets\_widget.scss 566:3 @import ..\base\_core.scss 60:9 @import main.scss 5:9 root stylesheet

Looks like the $selector value in _mixins.scss isn't getting set properly, but I can't see where that variable gets assigned.

EDIT: Looks like line 501 in _Widget.scss calls loopingProgressBar, passing 20% instead of a selector:
@include loopingProgressBar($looping_progress_bar_width);
Removing that line lets it successfully compile.

[mattheworres]

I've found this to be the case as well, though the issue here is not with this library per se, but rather with the JSApi (specifically, the 4master branch here: https://github.com/Esri/arcgis-js-api/tree/4master )

I've forked that repository, and if I have a chance (not looking likely) I may attempt to fix and then put a PR up, but looks like the issue tracker was disabled over there which is disappointing.

[jcfranco]

Sorry for the delay. 😅 Is this still an issue? If so, can you share more details about your workflow?

[NidanSki]

This issue is still there and as @mattheworres mentioned, is with the ArcGIS API for JavaScript.
This issue has been around for a while and is deployed with the the latest arcgis-js-api@4.16.2 package.

To resolve, as @romleinster mentioned, remove or comment out line 572 of the node_modules\arcgis-js-api\themes\base\widgets_Widget.scss file.

The issue is on Esri. In each of the main.css files you can download for the ten available themes cited on this page ArcGIS API Styling, you will see that from line 2169 there are three invalid rules (20% is repeated four time). The error can also be found in the view.css file.

Esri have deployed their CSS files from their SASS files, which contain the root cause of this issue. At least Esri eat their own dogfood.

[jcfranco]

@romleinster @NidanSki Thanks for the detailed report. I'm not sure why I couldn't reproduce this before. In any case, this has been fixed on the JS API-side and this issue should be resolved in the next release.