I am setting up a Snowpack project with the aim to move an existing Create-React-App application into it once things are configured the same.
I haven't found a way to import an .scss file into a .tsx file however.
The Snowpack docs only seem to discuss configuring scss as an externally built asset, suggesting putting your scss into a separate css folder { docs link }. However I would like to keep my scss files next to the tsx components they belong to, and import them into the component as I currently am.
The docs also reference a blog post discussing a setup with PostCSS, however that post suggests some issues with the approach, including that sourcemaps wouldn't work - which isn't going to fly.
I have created my project like this:
npx create-snowpack-app my-sweet-app --template #snowpack/app-template-react-typescript --use-yarn
I've then added a new scss file, src/test.scss
$best-colour: tomato;
body {
background-color: $best-colour;
}
and added an import in my src/App.tsx file:
import './test.scss';
When running yarn start I get the following error:
[error] [404] /_dist_/test.css.proxy.js
✘ /home/me/repos/my-sweet-app/public/_dist_/test.css
✘ /home/me/repos/my-sweet-app/src/test.css
Can Snowpack be configured to import scss files into tsx files equivalent to how it works in Create React App? How?
While I have not a complete answer, I faced the same problem as you. What you basically want to achieve is, to add additional tools to Snowpack's build pipeline.
If you throw in Babel with Snowpack you can add arbitrary absurd babel plugins for all your transformation needs.
Using #researchgate/babel-plugin-transform-scss-import-to-string and adding it in my babel.config.js I was able to get my Sassy stuff transpiled into strings.
However, this is not a complete solution; because now Snowpack won't pick up changes in my Sass files... :( It seem's that a lot of those new anti bundlers are just that, they are against bundling and thus combining them with additional pre-processing stuff that used to be done by our good olde bundlers is cumbersome.
Related
We have a Vue component library built with Rollup. The development is in early stage but everything worked well so far besides this one thing: we are not able to export SASS variables from a scss file and import them in a js file. We are used to do it using the :export statement of Webpack sass-loader. Something like this:
breakpoint.scss
#import './unit.scss';
$breakpoint-mobile: 360px;
$breakpoint-tablet: 768px;
$breakpoint-desktop: 1200px;
:export {
mobile: strip-unit($breakpoint-mobile);
tablet: strip-unit($breakpoint-tablet);
desktop: strip-unit($breakpoint-desktop);
}
then in any js file, we could import the stylesheet import breakpoints from '#/styles/settings/breakpoints.scss' where breakpoints will be equal to { mobile: '360', tablet: '768', desktop: '1200' }.
So it works fine with Webpack, but I can't get it working with Rollup using rollup-plugin-styles without additional config (I also tried rollup-plugin-postcss, same result). I also can't find anything on Google related to that issue...
This is the result of breakpoints.scss compiled by Rollup:
import n from '../../node_modules/rollup-plugin-styles/dist/runtime/inject-css.js';
var css = ":export{mobile:360;tablet:768;desktop:1200;}";
n(css,{});
export default css;
export { css };
//# sourceMappingURL=breakpoints.scss.js.map
So it seems like it wants to inject the styles which makes sense, but still not the behavior I want. Is it already possible to achieve what I'm looking for or I need to contribute to rollup-plugin-styles to add the support?
Update: it looks like this is supported, please see the answer provided by pmrotule.
Old answer:
The feature you are referring to is Interoperable CSS (ICSS).
As you have stated, the popular css-loader for webpack-based projects supports it.
As far as I can tell rollup-plugin-styles does currently not support Interoperable CSS. This is one of the reasons I still use webpack for my projects.
There is an open issue for this feature.
Contributing to the project and adding support for ICSS is a great idea, but expect some discussion about how the configuration will look like.
I just realized that if I use the option modules: true of rollup-plugin-styles, I get the behavior I was looking for... More details in the README.
I'm trying to figure out the right way to debug apps written in NativeScript-Vue AND using the "vue-cli-template".
There are currently two templates supported:
"nativescript-vue-template"
This one is much simpler, and debugging it is easy. There is a useful answer on that already. The debugging is done using chrome-devtools. This template doesn't use vue-cli/Webpack/Babel, so the "Sources" that you can view in Chrome are not changed in any way. You can easily set breakpoints there.
Just run e.g.:
tns debug android
You can also use the very nice VS Code plugin.
"vue-cli-template"
This one uses vue-cli/Webpack/Babel, so that the .vue Single File Components can be compiled in different ways.
Using a fresh install of the "vue-cli-template" as an example:
Run:
npm run debug:android
When you view the "Sources" of the "Hello world" demo app provided in the template, the app.js file has 17700 lines of code. It is basically the compiled dist/app/app.android.js file.
I've got some experience with vue-cli based applications. In an application configured according to the Vue documentation, when you view the "Sources" in Chrome dev-tools, apart from the compiled sources you can access the "webpack://" node, which contains the original code. You can set breakpoints there and it works.
Unfortunately the "vue-cli-template" does not work this way. There is no "webpack://" node available. You can only access the compiled sources.
I tried to follow the mentioned Vue documentation to fix this. I'm supposed to add
module.exports = {
configureWebpack: {
devtool: 'source-map'
}
}
to the vue.config.js file.
The template does not have it. Should I create one? If so, where?
Maybe I need other Webpack configurations?
devtool: 'source-map'
recommended in Vue documentation doesn't work in this setup.
It started working when I used:
devtool: 'eval-source-map'
after reading Webpack documentation.
I added this option directly to the webpack.config.js file - without using any vue.config.js file.
I have a directory of assets - favicon, sitemap.xml, etc - which are not referenced by my application, but which should be collected during my webpack build. This is trivial to do with other build tools like Grunt or Gulp, but I'm absolutely stumped on how to get Webpack to do this.
One way to sort of solve this is to use copy-loader. Keep in mind that Webpack is primarily a module bundler so this use case goes beyond it. It's more than fine to use Webpack with some other tools that are better suited for copying files.
I'm using CodeKit 2.1.8
I was using Foundation 5.4.6 but got in to some problems and updated to 4.5.7 now I still have some problems but different ones.
I was using Sass version 3.4.7 but downgraded to 3.2.19 after reading this could help. This did not help so I updates back to 3.4.7.
Right now my problem is as follows:
I have foundation installed through CodeKit. I did not alter die bower component files, everything is as is.
I have two projects accessing the bower component folder. My folder structure is as follows:
zurb-foundation
bower_components
dsl
css
img
js
scss
index.html
header
css
img
js
scss
index.html
.bowerrc
bower.json
config.codekit
package.json
The Sass files in both the dsl and header folder are completely identical. But they compile different.
Right now the dsl app.css file has about 15000 rows where the header app.css file has about 5000 rows.
I compared them and there are a lot of differences. All of the styles and components get loaded but it looks like the styles get multiple times in the dsl/app.css. Another difference is that the header folder has no sass-cache folder but the dsl folder has got a folder called sass-cache.
So there are some compilation differences does anyone has encountered this before?
Thank you
I also posted this question in the Foundation forum. Rafi Benkual provided me with this answer:
Have you tried Libsass? Here is the recommendation from Codekit:
Sass Update
"Keep using Libsass to compile Sass files in a Zurb Foundation project because the latest Ruby Sass compiler (3.4.5) is not yet supported by Foundation. This should clear up in the next few weeks. See the link in the 2.1.7 release notes, below, for more information."
In CodeKit 2 you can find "Use the libsass compiler" checkbox under "Other options:" on the .scss file's settings panel (on right).
This worked for me.
Anyone doing development with meteor and SCSS. How do you get started, there are no packages for meteorite that i could find that compile .scss files into a specific folder?
Have you tried just compiling the sass/scss into css locally during development? Meteor shouldn't complain if you have your config.rb inside of the client folder along with a sass folder and compiled css folder. It should just automatically read the css per norm. Running $ compass watch inside of this client folder where the config.rb resides is an easy way to automate this css compilation. Telescope is a great sample Meteor app that uses sass in this fashion.
--Alex
Just to get this posted as an answer (was posted as comment); bookcasey posted this sample project as well: https://github.com/gdumitrescu/scoreboard which provides some guidance on how to use sass/scss. Hope it helps.