Giter VIP home page Giter VIP logo

dart-sass's Introduction

A Dart implementation of Sass. Sass makes CSS fun.

Sass logo npm statistics Pub version
GitHub actions build status
@SassCSS on Twitter
stackoverflow
Gitter

Using Dart Sass

There are a few different ways to install and run Dart Sass, depending on your environment and your needs.

From Chocolatey or Scoop (Windows)

If you use the Chocolatey package manager or the Scoop package manager for Windows, you can install Dart Sass by running

choco install sass

or

scoop install sass

That'll give you a sass executable on your command line that will run Dart Sass. See the CLI docs for details.

From Homebrew (macOS or Linux)

If you use the Homebrew package manager, you can install Dart Sass by running

brew install sass/sass/sass

That'll give you a sass executable on your command line that will run Dart Sass.

Standalone

You can download the standalone Dart Sass archive for your operating system—containing the Dart VM and the snapshot of the executable—from the GitHub release page. Extract it, add the directory to your path, restart your terminal, and the sass executable is ready to run!

From npm

Dart Sass is available, compiled to JavaScript, as an npm package. You can install it globally using npm install -g sass which will provide access to the sass executable. You can also add it to your project using npm install --save-dev sass. This provides the executable as well as a library:

const sass = require('sass');

const result = sass.compile(scssFilename);

// OR

// Note that `compileAsync()` is substantially slower than `compile()`.
const result = await sass.compileAsync(scssFilename);

See the Sass website for full API documentation.

Dart Sass in the Browser

The sass npm package can also be run directly in the browser. It's compatible with all major web bundlers as long as you disable renaming (such as --keep-names in esbuild). You can also import it directly from a browser as an ECMAScript Module without any bundling (assuming node_modules is served as well):

<script type="importmap">
  {
    "imports": {
      "immutable": "./node_modules/immutable/dist/immutable.es.js",
      "sass": "./node_modules/sass/sass.default.js"
    }
  }
</script>

<!-- Support browsers like Safari 16.3 without import maps support. -->
<script async src="https://unpkg.com/es-module-shims@^1.7.0" crossorigin="anonymous"></script>

<script type="module">
  import * as sass from 'sass';

  console.log(sass.compileString(`
    .box {
      width: 10px + 15px;
    }
  `));
</script>

Or from a CDN:

<script type="importmap">
  {
    "imports": {
      "immutable": "https://unpkg.com/immutable@^4.0.0",
      "sass": "https://unpkg.com/sass@^1.63.0/sass.default.js"
    }
  }
</script>

<!-- Support browsers like Safari 16.3 without import maps support. -->
<script async src="https://unpkg.com/es-module-shims@^1.7.0" crossorigin="anonymous"></script>

<script type="module">
  import * as sass from 'sass';

  console.log(sass.compileString(`
    .box {
      width: 10px + 15px;
    }
  `));
</script>

Or even bundled with all its dependencies:

<script type="module">
  import * as sass from 'https://jspm.dev/sass';

  console.log(sass.compileString(`
    .box {
      width: 10px + 15px;
    }
  `));
</script>

Since the browser doesn't have access to the filesystem, the compile() and compileAsync() functions aren't available for it. If you want to load other files, you'll need to pass a custom importer to compileString() or compileStringAsync(). The legacy API is also not supported in the browser.

Legacy JavaScript API

Dart Sass also supports an older JavaScript API that's fully compatible with Node Sass (with a few exceptions listed below), with support for both the render() and renderSync() functions. This API is considered deprecated and will be removed in Dart Sass 2.0.0, so it should be avoided in new projects.

Sass's support for the legacy JavaScript API has the following limitations:

  • Only the "expanded" and "compressed" values of outputStyle are supported.

  • Dart Sass doesn't support the precision option. Dart Sass defaults to a sufficiently high precision for all existing browsers, and making this customizable would make the code substantially less efficient.

  • Dart Sass doesn't support the sourceComments option. Source maps are the recommended way of locating the origin of generated selectors.

Using Sass with Jest

If you're using Jest to run your tests, be aware that it has a longstanding bug where its default test environment breaks JavaScript's built-in instanceof operator. Dart Sass's JS package uses instanceof fairly heavily, so in order to avoid breaking Sass you'll need to install jest-environment-node-single-context and add testEnvironment: 'jest-environment-node-single-context' to your Jest config.

From Pub

If you're a Dart user, you can install Dart Sass globally using pub global activate sass, which will provide a sass executable. You can also add it to your pubspec and use it as a library. We strongly recommend importing it with the prefix sass:

import 'package:sass/sass.dart' as sass;

void main(List<String> args) {
  print(sass.compile(args.first));
}

See the Dart API docs for details.

sass_api Package

Dart users also have access to more in-depth APIs via the sass_api package. This provides access to the Sass AST and APIs for resolving Sass loads without running a full compilation. It's separated out into its own package so that it can increase its version number independently of the main sass package.

From Source

Assuming you've already checked out this repository:

  1. Install Dart. If you download an archive manually rather than using an installer, make sure the SDK's bin directory is on your PATH.

  2. Install Buf. This is used to build the protocol buffers for the embedded compiler.

  3. In this repository, run dart pub get. This will install Dart Sass's dependencies.

  4. Run dart run grinder protobuf. This will download and build the embedded protocol definition.

  5. Run dart bin/sass.dart path/to/file.scss.

That's it!

In Docker

You can install and run Dart Sass within Docker using the following Dockerfile commands:

# Dart stage
FROM bufbuild/buf AS buf
FROM dart:stable AS dart

# Add your scss files
COPY --from=another_stage /app /app

# Include Protocol Buffer binary
COPY --from=buf /usr/local/bin/buf /usr/local/bin/

WORKDIR /dart-sass
RUN git clone https://github.com/sass/dart-sass.git . && \
  dart pub get && \
  dart run grinder protobuf
# This is where you run sass.dart on your scss file(s)
RUN dart ./bin/sass.dart /app/sass/example.scss /app/public/css/example.css

Why Dart?

Dart Sass has replaced Ruby Sass as the canonical implementation of the Sass language. We chose Dart because it presented a number of advantages:

  • It's fast. The Dart VM is highly optimized, and getting faster all the time (for the latest performance numbers, see perf.md). It's much faster than Ruby, and close to par with C++.

  • It's portable. The Dart VM has no external dependencies and can compile applications into standalone snapshot files, so we can distribute Dart Sass as only three files (the VM, the snapshot, and a wrapper script). Dart can also be compiled to JavaScript, which makes it easy to distribute Sass through npm, which the majority of our users use already.

  • It's easy to write. Dart is a higher-level language than C++, which means it doesn't require lots of hassle with memory management and build systems. It's also statically typed, which makes it easier to confidently make large refactors than with Ruby.

  • It's friendlier to contributors. Dart is substantially easier to learn than Ruby, and many Sass users in Google in particular are already familiar with it. More contributors translates to faster, more consistent development.

Compatibility Policy

For the most part, Dart Sass follows semantic versioning. We consider all of the following to be part of the versioned API:

  • The Sass language semantics implemented by Dart Sass.
  • The Dart API.
  • The JavaScript API.
  • The command-line interface.

Because Dart Sass has a single version that's shared across the Dart, JavaScript, and standalone distributions, this may mean that we increment the major version number when there are in fact no breaking changes for one or more distributions. However, we will attempt to limit the number of breaking changes we make and group them in as few releases as possible to minimize churn. We strongly encourage users to use the changelog for a full understanding of all the changes in each release.

There is one exception where breaking changes may be made outside of a major version revision. It is occasionally the case that CSS adds a feature that's incompatible with existing Sass syntax in some way. Because Sass is committed to full CSS compatibility, we occasionally need to break compatibility with old Sass code in order to remain compatible with CSS.

In these cases, we will first release a version of Sass that emits deprecation warnings for any stylesheets whose behavior will change. Then, at least three months after the release of a version with these deprecation warnings, we will release a minor version with the breaking change to the Sass language semantics.

Browser Compatibility

In general, we consider any change to Dart Sass's CSS output that would cause that CSS to stop working in a real browser to be a breaking change. However, there are some cases where such a change would have substantial benefits and would only negatively affect a small minority of rarely-used browsers. We don't want to have to block such a change on a major version release.

As such, if a change would break compatibility with less than 2% of the global market share of browser according to StatCounter GlobalStats, we may release a minor version of Dart Sass with that change.

Node.js Compatibility

We consider dropping support for a given version of Node.js to be a breaking change as long as that version is still supported by Node.js. This means that releases listed as Current, Active LTS, or Maintenance LTS according to the Node.js release page. Once a Node.js version is out of LTS, Dart Sass considers itself free to break support if necessary.

Invalid CSS

Changes to the behavior of Sass stylesheets that produce invalid CSS output are not considered breaking changes. Such changes are almost always necessary when adding support for new CSS features, and delaying all such features until a new major version would be unduly burdensome for most users.

For example, when Sass began parsing calc() expressions, the invalid expression calc(1 +) became a Sass error where before it was passed through as-is. This was not considered a breaking change, because calc(1 +) was never valid CSS to begin with.

Embedded Dart Sass

Dart Sass includes an implementation of the compiler side of the Embedded Sass protocol. It's designed to be embedded in a host language, which then exposes an API for users to invoke Sass and define custom functions and importers.

Usage

  • sass --embedded starts the embedded compiler and listens on stdin.
  • sass --embedded --version prints versionResponse with id = 0 in JSON and exits.

The --embedded command-line flag is not available when you install Dart Sass as an npm package. No other command-line flags are supported with --embedded.

Behavioral Differences from Ruby Sass

There are a few intentional behavioral differences between Dart Sass and Ruby Sass. These are generally places where Ruby Sass has an undesired behavior, and it's substantially easier to implement the correct behavior than it would be to implement compatible behavior. These should all have tracking bugs against Ruby Sass to update the reference behavior.

  1. @extend only accepts simple selectors, as does the second argument of selector-extend(). See issue 1599.

  2. Subject selectors are not supported. See issue 1126.

  3. Pseudo selector arguments are parsed as <declaration-value>s rather than having a more limited custom parsing. See issue 2120.

  4. The numeric precision is set to 10. See issue 1122.

  5. The indented syntax parser is more flexible: it doesn't require consistent indentation across the whole document. See issue 2176.

  6. Colors do not support channel-by-channel arithmetic. See issue 2144.

  7. Unitless numbers aren't == to unit numbers with the same value. In addition, map keys follow the same logic as ==-equality. See issue 1496.

  8. rgba() and hsla() alpha values with percentage units are interpreted as percentages. Other units are forbidden. See issue 1525.

  9. Too many variable arguments passed to a function is an error. See issue 1408.

  10. Allow @extend to reach outside a media query if there's an identical @extend defined outside that query. This isn't tracked explicitly, because it'll be irrelevant when issue 1050 is fixed.

  11. Some selector pseudos containing placeholder selectors will be compiled where they wouldn't be in Ruby Sass. This better matches the semantics of the selectors in question, and is more efficient. See issue 2228.

  12. The old-style :property value syntax is not supported in the indented syntax. See issue 2245.

  13. The reference combinator is not supported. See issue 303.

  14. Universal selector unification is symmetrical. See issue 2247.

  15. @extend doesn't produce an error if it matches but fails to unify. See issue 2250.

  16. Dart Sass currently only supports UTF-8 documents. We'd like to support more, but Dart currently doesn't support them. See dart-lang/sdk#11744, for example.

Disclaimer: this is not an official Google product.

dart-sass's People

Contributors

adamhooper avatar airstarsasia avatar awjin avatar dependabot[bot] avatar goodwine avatar jamesnw avatar jathak avatar jerivas avatar jmooring avatar m4r71n avatar matanlurey avatar mattfelten avatar mcrumm avatar mgreter avatar michaelrfairhurst avatar mstrodl avatar natebosch avatar nex3 avatar nickbehrens avatar nschonni avatar nshahan avatar nstringham avatar ntkme avatar olleolleolle avatar pamelalozano16 avatar pjeweb avatar rafer45 avatar sassbot avatar srawlins avatar stof avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dart-sass's Issues

Contributing oddness.

In the README.md it says:

Disclaimer: this is not an official Google product.

In the CONTRIBUTING.md it says:

Before we can use your code, you must sign the
Google Individual Contributor License Agreement
(CLA), which you can do online.

I fail to see the correlation in me having to sign the CLA if I want to contribute if this is not an official Google Product.

Care to explain? This seems really weird to me.

Test on AppVeyor

Since #55 adds CLI tests, it's now relevant to test across operating systems to avoid bugs like #51. AppVeyor seems like the best place to do this. It should be fairly straightforward to port the Travis config, especially since we only care about running unit tests against Dart and Node.

Extra newline inserted with semicolon in missing

Test using the npm package

@media all and (min-width: 100px) {
  @import "https://example.org"
}

Ruby Sass

@media all and (min-width: 100px) {
  @import "https://example.org";
}

Dart Sass 1.0.0-alpha.4

@media all and (min-width: 100px) {
  @import "https://example.org"
;
}

Support inline-font-files?

This is a question/feature request.

Since Compass doesn't work with dart-sass, what would the recommended way to get fonts inlined be?
Is providing something like Compass' inline-font-files helper out of scope for dart-sass?
Our current build processes and git merge-drivers rely on running a single command to compile Sass, so it would be nice to be able to switch to dart-sass without having to introduce another step that inlines the fonts.

Thanks!

JS API: Support full render() return value

We need to support the full API of the object returned by node-sass's render() API, both in the success case and in the error case. The only exception is the map field, which won't be set until we support source maps (#2).

Benchmarks: Record Dart VM time with JIT'd/warm code

At least internally, we spin up a worker and use it for incremental rebuilds. This means the code/snapshot is already loaded, already JITd, and kept warm for the development cycle. This is more likely than spinning up to do a one-time build and closing.

Make the JS version faster

The JS-compiled version of Dart Sass hovers around 2.5x and 3x slower than when running on the Dart VM. Some slowdown is inevitable, but this seems extreme. We should put dedicated effort into profiling the JS output and optimizing hot spots.

Consistent command-line arguments

It would be easier to switch between different Sass compilers, if each of them would use the exact same command-line arguments. While dart-sass doesn't (yet) offer all of the same features as its brothers, there are already some differences.

For example, in dart-sass the shorthand for --style is -s, while it's -t in both,sass and sassc. In dart-sass the shorthand for --color is -c, while-c is used as the shorthand for --check in sass.

I understand that there might be no plans to bring all the features of sass (or sassc) to dart-sass, yet I think the advantages of consistent arguments are obvious.

JS API: Support formatting options

We need to support the node-sass API's options for formatting its output:

  • indentType controls whether tabs or spaces are emitted.
  • indentWidth controls how many tabs or spaces are emitted per indentation.
  • linefeed, which controls what line break sequence to use in the resulting CSS.
  • outputStyle, which controls the style of CSS emitted. Note that this will only support the value expanded for the time being, and unlike node-sass, it will default to expanded.

Error when calling a built in function from an import

Reproduce with the example:

test/
├── bar/
│   ├── _bar.scss
├── foo.scss

foo.scss contains the lines:

@import 'bar/bar';
body {
  background: $color;
}

_bar.scss contains the line:

$color: rgba(#000, 1);

When I run dart-sass I get the following stack trace:

$ dart ../dart-sass/bin/sass.dart foo.scss
Unexpected exception:
RangeError (index): Invalid value: Only valid value is 0: 1

dart:core                                                            List.[]
package:sass/src/environment.dart 198:41                             Environment.getFunction
package:sass/src/visitor/perform.dart 927:50                         _PerformVisitor.visitFunctionExpression
package:sass/src/ast/sass/expression/function.dart 32:15             FunctionExpression.accept
package:sass/src/visitor/perform.dart 784:36                         _PerformVisitor.visitVariableDeclaration
package:sass/src/ast/sass/statement/variable_declaration.dart 39:15  VariableDeclaration.accept
package:sass/src/visitor/perform.dart 505:21                         _PerformVisitor._visitDynamicImport.<fn>.<fn>
package:sass/src/visitor/perform.dart 1276:26                        _PerformVisitor._withEnvironment
package:sass/src/visitor/perform.dart 503:7                          _PerformVisitor._visitDynamicImport.<fn>
package:sass/src/visitor/perform.dart 1361:26                        _PerformVisitor._withStackFrame
package:sass/src/visitor/perform.dart 502:5                          _PerformVisitor._visitDynamicImport
package:sass/src/visitor/perform.dart 490:9                          _PerformVisitor.visitImportRule
package:sass/src/ast/sass/statement/import_rule.dart 22:15           ImportRule.accept
package:sass/src/visitor/perform.dart 157:13                         _PerformVisitor.visitStylesheet
package:sass/src/visitor/perform.dart 147:5                          _PerformVisitor.run
package:sass/src/visitor/perform.dart 46:10                          evaluate
package:sass/sass.dart 24:17                                         render
package:sass/src/executable.dart 50:15                               main

Node Version support

I see you have the engine set to >=0.10.0. Is that the intended support, because I am having some issues with v4.x?

Error with 1.0.0-alpha.4 on Windows

On Windows CMD and GitBash, it seems path seperator often cause some error.

Test the following code, where ./test.scss is any given valid scss file in the same folder:

var sass = require('dart-sass');
var res = sass.renderSync({ file: './test.scss' });
console.log(res);

Then got:

image

In dart.Uri_parse‘s body, insert a new line at the begining, uri = uri.replace(/\\/g, '/') will work,

So this maybe a problem to be solved.

Support Microsoft-style binary = operator

  filter: alpha(opacity=$opacity-ie);
                        ^
@mixin opacity($opacity) {
  opacity: $opacity;
  // IE8 filter
  $opacity-ie: ($opacity * 100);
  filter: alpha(opacity=$opacity-ie);
}

JS API: Support custom functions

We need to support the node-sass API's functions option, which specifies custom functions that can be called from Sass stylesheets. This will involve exposing SassScript objects, and making them API-compatible with node-sass.

Find a representative suite of stylesheets

Right now, we do our benchmarking and application snapshot training on artificial files full of many repeated style rules that are individually very simple. These are useful for measuring a few aspects of performance, but they aren't representative of the performance characteristics of real-world Sass. We need to find a collection of stylesheets, ideally those pulled from real apps, that we can use instead or in addition.

Add information on how to use the new package in a dart project

I understand that this is still in alpha, so this might be a bit premature, but since there is no transformer anymore, I wonder how this is supposed to be used within a dart project. Is this already assuming that Bazel will be used in the future to build projects? Or is it planned that the transformer would be able to use the dart sass package?

Support source maps

We need to support source maps, as close to Ruby Sass and LibSass as possible. Hopefully this shouldn't be too difficult, since we're already tracking source spans everywhere.

  • Add support to the Dart API.
  • Add support to the JS API.
  • Add support to the CLI.
  • Track variable definitions.

JS API: Create a method to get SASS AST

I want to implement SASS parser for @postcss - written by @ai. But for this purpose I need convert SASS AST to PostCSS AST. It would be great, if I can use official parser from @sass (i'm really appreciate that you implemented SASS on compiled to JS language).

So, @nex3 - what you think if I will try to write a new method which return SASS AST? I'm newbie in @Dart, so it will take some time to learn it:D I think it will be a method very similar to render() from node-sass.

Invalid output - comment blocks do not get closed

I attempted to compile MDL's SCSS files with dart-sass as a test, unfortunately I ran into an issue. Given the following sample partial:

/**
* Whatever comment
**/
@import "color-definitions";
/* close comment block */
$preferred_font: 'Roboto', 'Helvetica', 'Arial', sans-serif !default;

The output contains @import "color-definitions"; Other than that it seems to be ok. I believe it's related to loudComments. I ran a couple more tests:

1) If I remove the 2nd comment block, the the compilation fails:

Error on line 7, column 1 of web\_p2.scss: expected more input.

^
package:sass/src/parse/parser.dart 518:7                    Parser.wrapSpanFormatException
package:sass/src/parse/stylesheet.dart 63:12                StylesheetParser.parse
package:sass/src/ast/sass/statement/stylesheet.dart 40:56   Stylesheet.Stylesheet.parseScss
package:sass/src/visitor/perform.dart 541:17                _PerformVisitor._loadImport.<fn>
dart:collection                                             _HashVMBase&MapMixin&&_LinkedHashMapMixin.putIfAbsent
package:sass/src/visitor/perform.dart 536:27                _PerformVisitor._loadImport
package:sass/src/visitor/perform.dart 502:22                _PerformVisitor._visitDynamicImport
package:sass/src/visitor/perform.dart 492:9                 _PerformVisitor.visitImportRule
package:sass/src/ast/sass/statement/import_rule.dart 22:15  ImportRule.accept
package:sass/src/visitor/perform.dart 157:13                _PerformVisitor.visitStylesheet
package:sass/src/visitor/perform.dart 147:5                 _PerformVisitor.run
package:sass/src/visitor/perform.dart 46:10                 evaluate
package:sass_builder/src/compilation_strategies.dart 27:19  DartSassCompilationStrategy._renderScss
... ...

2) If I adjust the source to look like so (removed a * from the block comment closing):

/**
* Whatever comment
*/
@import "color-definitions";
/* close comment block */
$preferred_font: 'Roboto', 'Helvetica', 'Arial', sans-serif !default;

Everything is happy and good.

With a little quirk in ScssParser class things seem to work. (Attached the diff - typo in filename :S )
parser-patch.txt

Allow direct symlinks to dart-sass

Currently dart-sass doesn't work in Linux when you call it through a symlink located on a different path.

It's common practice to install a package in one place and create a symlink to the binary from a location already in $PATH. E.g.:

sudo ln -sf $HOME/Downloads/dart-sass/dart-sass /usr/local/bin/sass

$ dart-sass --version
/usr/local/bin/sass: line 11: /usr/local/bin/src/dart: No such file or directory

In order for this to work the path resolution must be changed from:

path=`dirname "$0"`

to:

path="$(dirname "$(readlink -f "$0")")"

This expression correctly returns the directory of the script, and supports calling the binary directly linked through a symlink. It is posix compatible, and it has been tested with posh (Policy-compliant Ordinary SHell).

The only problem with it is that it is not compatible with Mac OS X, because apparently it doesn't support the -f flag in readlink, under normal conditions. And I can see the same script is used for Mac OS too.

So the simplest way I can see to support both cases, is to check first if the target path can be resolved, and only if it fails, use the new resolution formula. Like this:

path=$(dirname "$0")
if [ ! -f "$path/src/dart" ]; then
    path="$(dirname "$(readlink -f "$0")")"
fi

NoSuchMethodError: method not found: 'call'

Tried a simple test on my machine and got the following error.

/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:10549
        throw H.wrapException(P.NoSuchMethodError$(this, invocation.get$memberName(), invocation.get$positionalArguments(), invocation.get$namedArguments(), null));
        ^

NoSuchMethodError: method not found: 'call'
Receiver: Closure '_render'
Arguments: [Instance of 'PlainJavaScriptObject']
    at Object.wrapException (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:4154:17)
    at StaticClosure.noSuchMethod$1 (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:10549:17)
    at Object.J.noSuchMethod$1$ (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:31521:39)
    at Object.Primitives_functionNoSuchMethod (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:4050:16)
    at Object.Primitives__genericApplyFunctionWithPositionalArguments (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:4091:20)
    at Object.Primitives_applyFunctionWithPositionalArguments (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:4077:16)
    at dart._callDartFunctionFast (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:13268:16)
    at Object.render (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/node_modules/dart-sass/sass.dart.js:13260:18)
    at Object.<anonymous> (/Users/Wayne/src/github.com/wayneashleyberry/styleguide/test.js:2:19)
    at Module._compile (module.js:573:32)

The command I ran was node test.js, here are the contents of test.js:

var sass = require('dart-sass');

var result = sass.render({
    'file': 'assets/sass/main.scss'
});

console.log(result)

The contents of assets/sass/main.scss are:

$font-stack: Helvetica, sans-serif;
$primary-color: #333;

body {
  font: 100% $font-stack;
  color: $primary-color;
}

I'm running node v7.0.0, macOS 10.12.1 and tried installing dart-sass with both yarn 0.16.1 and npm 3.10.9

"Expected tabs, was spaces." error

I want to get CSS from SASS with npm package. I run that code:

var sass = require('dart-sass');

scss_filename = "basic.sass"

sass.render({file: scss_filename}, function(err, result) {
  console.log(result);
  console.log(err);
});

And every time I get an error: "Expected tabs, was spaces."
To make sure, that is no error in my markdown of SASS in a text editor (I'm using Sublime Text). I download a file from your tests in sass repo. But I still have the same error. The result is:

null
{ message: 'Expected tabs, was spaces.' }

Am I doing something wrong?

Set up automated or semi-automated benchmarking infrastructure

To measure benchmarks today, I just manually run a bunch of different options by hand, which takes a long time and is prone to mistakes. We should at least have a script to run all benchmarks and collate the output, and ideally we should run that script automatically if we can find a way to do that without varying the underlying specifications too dramatically.

Invalid nested CSS

SCSS example:

$state: active;
$background: white;

.table-hover > tbody > tr {
  > td.#{$state}:hover,
  > th.#{$state}:hover,
  &.#{$state}:hover > td,
  &:hover > .#{$state},
  &.#{$state}:hover > th {
    background-color: darken($background, 5%);
  }
}

Compiles to INVALID:

> td.active:hover, > th.active:hover, .table-hover > tbody > tr.active:hover > td, .table-hover > tbody > tr:hover > .active, .table-hover > tbody > tr.active:hover > th {
  background-color: #f2f2f2;
}

Should be:

.table-hover > tbody > tr > td.active:hover,
.table-hover > tbody > tr > th.active:hover,
.table-hover > tbody > tr.active:hover > td,
.table-hover > tbody > tr:hover > .active,
.table-hover > tbody > tr.active:hover > th {
  background-color: #f2f2f2;
}

Use DDC for JS compilation

The Dart dev compiler produces much nicer-looking JavaScript output than dart2js, and makes JavaScript interop much nicer by guaranteeing that all Dart objects can be used directly in JS without extra wrappers. This will be very useful for custom functions, which will need to be able to interact with SassScript values with as little overhead as possible.

This is currently blocked on dart-lang/sdk#27607.

Extend edge-case is handled inefficiently

The following code:

a {b: c}

@for $n from 1 through 100 {
  @for $i from 1 through 100 {
    x#{$i} { @extend a; }
  }
}

Takes approximately 45s to compile on Dart Sass, and produces hundreds of redundant selectors. it takes about 2s on Ruby Sass and 300ms on LibSass, and produces output with redundant selectors optimized out.

I suspect that something is wrong in how we're batching up groups of selectors before trimming. The pre-existing selectors shouldn't be compared against each other and shouldn't count against the 100-chunk limit, but this doesn't seem to be the case.

See sass/libsass#2253 (comment).

Prefix functions

sass-darken() instead of darken(). This was supposed to make it into Sass v4, but it'd be awesome to get it in here asap.

See sass#2078 for more information.

JS API: Support full error value

When dart-sass detects an error in a .scss file, it invokes the callback with an err object that contains message, but there's no file/line info for correlation.

Steps to reproduce

  1. Install dart-sass 1.0.0-alpha.8 with: npm install dart-sass
  2. Create a Gulp task that calls dart-sass like this:
dartSass.render({file: file.path}, (err, result) => {
    if (err) {
      console.error('sass error', err);
    } else {
      file.contents = result.buffer;
    }
    cb(err, file);
});
  1. Pipe the following file to dart-sass:

foo.scss:

:host {
  display: block;
  padding: 10px;

  --view1-card: {
    'foo   /* intentionally unterminated string */
  }
}

Expected result

The callback's err object included file and line info.

Actual result

Only message (without file/line info) is provided in err. The message contains:

Expected '.

Environment

  • dart-sass 1.0.0-alpha.8
  • node 7.5.0
  • gulp 3.9.1
  • macOS Sierra 10.12

Export Sass Transformer

The Dart ecosystem allows for transformers to be applied to various assets within a source directory at build time. By providing a transformer as part of the the dart-sass library it would be possible for SASS to be treated as a first class source file type in the pub build process; Simplifying the build tooling around a Dart web application.

Was on ruby sass but now trying out dart sass

Hi, I was wondering if there exists good documentation on how to switch from ruby sass to dart sass. For example, we use compass and have multiple import path right now using ruby sass and also via grunt plugin. Is there any documentation on how to do the same using dart sass?

Thanks

Unexpected exception:RangeError (index): Index out of range: index should be less than 1: 1

Im using: 1.0.0-alpha.1 compiled with dart2js 1.20.1
I got the following error:

Unexpected exception:RangeError (index): Index out of range: index should be less than 1: 1
node_modules/dart-sass/sass.dart.js 4154:17   wrapException
node_modules/dart-sass/sass.dart.js 4104:15   ioore
node_modules/dart-sass/sass.dart.js 17688:22  Environment.getFunction$1
node_modules/dart-sass/sass.dart.js 27465:66  _PerformVisitor.visitFunctionExpression$1
node_modules/dart-sass/sass.dart.js 16014:24  FunctionExpression.accept$1
node_modules/dart-sass/sass.dart.js 27370:75  _PerformVisitor.visitVariableDeclaration$1
node_modules/dart-sass/sass.dart.js 16637:24  VariableDeclaration.accept$1
node_modules/dart-sass/sass.dart.js 31349:41  J.accept$1$x
node_modules/dart-sass/sass.dart.js 28126:13  _PerformVisitor__visitDynamicImport__closure.call$0
node_modules/dart-sass/sass.dart.js 27703:27  _PerformVisitor._withEnvironment$2

My environment is:
package.json

{
  "name": "untitled",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "dart-sass ./src/main.scss dist/main.css  > ./dist/main.css"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "bootstrap-sass": "^3.3.7"
  },
  "devDependencies": {
    "dart-sass": "^1.0.0-alpha.1"
  }
}

src/main.scss

@import "../node_modules/bootstrap-sass/assets/stylesheets/_bootstrap";

node-sass compatibility

This is a meta-issue tracking all the issues necessary for the level of node-sass API compatibility that we want for 1.0.0:

  • #7: input options (file, data, includePaths, indentedSyntax)
  • #8: formatting options (indentType, indentWidth, linefeed, outputStyle)
  • #9: importer
  • #10: functions
  • #11: render() return value
  • #109: render() error

The following options will not be required for 1.0.0:

  • precision: Allowing the precision to be customized is challenging in terms of code structure, and may cause some small performance degradation in numerically-intensive tasks due to the lack of constant folding. Since Dart Sass defaults to a much larger precision anyway, we won't support this option for the time being.
  • sourceComments: Source comments are desirable, but low-priority.
  • omitSourceMapUrl, outFile, sourceMap, sourceMapContents, sourceMapEmbed, sourceMapRoot: source map support is not considered blocking for 1.0.0 (see #2).

Silently ignores errors in native CSS mixins

dart-sass happily ignores garbage inside native CSS mixins such as the following:

styles.scss

$color: #4285f4;
:host {
  display: block;
  padding: 10px;
  --view1-card: {
    border: solid 1px #{$color};
    foo();k;lfajkf;
    fdjkfldajl
  };
}

build.js:

const dartSass = require('dart-sass');
dartSass.render({file: 'styles.scss'}, (err: Error, result: Buffer) => {
  // ...
});

Running styles.scss through build.js results in no warnings or errors. The result contains the garbage as-is:

:host {
  display: block;
  padding: 10px;
  --view1-card: {
    border: solid 1px #4285f4;
    foo();k;lfajkf;
    fdjkfldajl
  };
}

I expected to see an error.

Environment

  • macOS Sierra 10.12
  • node 7.4.0
  • dart-sass 1.0.0-alpha.8

Edge case bug

Source:

%placeholder1 {
    display: none;
}

.class1 {
    @extend %placeholder1;
}

.class2:not(.class3):after {
    display: none;
}

dart-sass output:

.class1 {
  display: none;
}

.class2:not(.class3):not(.class3) {
  display: none;
}

node-sass output:

.class1 {
  display: none;
}

.class2:not(.class3):after {
  display: none;
}

Support package: URLs in Dart

@import statements should be able to resolve package: URLs when running in Dart mode. The CLI should probably also accept them as well for good measure. We'll want to do this by taking a SyncPackageResolver from the executable or the render() method.

"pub global activate dart-sass" does not work

$ pub global activate dart-sass
Resolving dependencies... (1.5s)
Could not find package dart-sass at https://pub.dartlang.org.

Environment:

$ dart --version
Dart VM version: 1.20.1 (Wed Oct 12 15:00:54 2016) on "macos_x64"

Css RGBA optimization

a {
  background-color: rgba(0, 0, 0, 0);
}

Should be generated as

a {
  background-color: transparent;
}

Support custom functions defined in Dart

We should support the ability for users to define custom functions using the Dart API. Unfortunately, we'll probably have to require that these functions be synchronous, which may limit their functionality, but I don't see a way around that.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.