EDIT: Meteor 1.3 release is out and a npm package is about to be released allowing a direct use of CSS modules without Webpack
I would like to use https://github.com/gajus/react-css-modules in Meteor 1.3 via NPM. But the readme says to use Webpack. I never used Webpack as it seems to me to do the same build job as Meteor.
So do you know a way, in this specific case, for using React Module CSS in Meteor 1.3 beta?
There is actually package for this. MDG is also considering bring webpacks on meteor core at some stage. And yes it is build tool. Just more modular and faster than current one. Its also pretty complex as build tools go, at least in my opinion.
To have webpacks in meteor just >
meteor add webpack:webpack
meteor remove ecmascript
You need to remove ecmascripts as you get them from webpack as well and having 2 installs can cause errors.
For much more complete answer check Sam Corcos blog post and also Ben Strahan's comment for Meteor 1.3 Beta. I used it as tutorial to get different webpack package up.
https://medium.com/#SamCorcos/meteor-webpack-from-the-ground-up-f123288c7b75#.phcq5lvm8
For package you mentioned I think webpack.packages.json should look something like this
{
"private": true,
"scripts": {
"start": "webpack-dev-server"
},
"devDependencies": {
"babel-core": "^6.4.5",
"babel-loader": "^6.2.1",
"babel-preset-es2015": "^6.3.13",
"babel-preset-react": "^6.3.13",
"babel-preset-stage-0": "^6.3.13",
"css-loader": "^0.23.1",
"extract-text-webpack-plugin": "^1.0.1",
"style-loader": "^0.13.0",
"webpack": "^2.0.6-beta",
"webpack-dev-server": "^2.0.0-beta"
},
"dependencies": {
"react": "^0.15.0-alpha.1",
"react-css-modules": "^3.7.4",
"react-dom": "^0.15.0-alpha.1"
}
And webpack.config.js you could copy directly from
https://github.com/gajus/react-css-modules-examples/blob/master/webpack.config.js
Meteor v1.3.2 introduced built-in import functionality for .css files (as well as other CSS preprocessor files, such as less and sass) from within .js and .jsx.
For example, given the following (simplified) folder structure,
.
├── client
│ └── main.js
├── imports
│ └── client
│ ├── main.css
│ └── main.jsx
├── node_modules
│ └── some-module
│ └── dist
│ └── css
│ └── main.css
├── package.json
└── server
└── main.js
where some-module is an npm module installed using:
$ meteor npm install --save some-module
importing local and module stylesheets in imports/client/main.jsx:
// importing a style file from a node module
import 'some-module/dist/css/main.css';
// importing a style from a local file
import './main.css';
You can start from scratch like this.
Start from scratch
meteor create test-project
cd test-project
npm init
meteor remove ecmascript
meteor add webpack:webpack
meteor add webpack:react
meteor add webpack:less
meteor add react-runtime # Skip this step if you want to use the NPM version
meteor add react-meteor-data
meteor
npm install
meteor
Entry files
Your entry files are defined within your package.json. The main is your server entry and the browser is your client entry.
{
"name": "test-project",
"private": true,
"main": "server/entry.js",
"browser": "client/entry.js"
}
For more info please check this link
Related
There are SSR-related problems with several pages in Next.js project that results in errors on npm run build and prevent the project from being built:
pages/
foo/
bar/
[id].jsx
index.jsx
index.jsx
...
For example, bar:
export function getStaticProps() {
return someApiCallThatCurrentlyFails()
...
}
export default function Bar() {...}
As a quick fix, it may be convenient to just not build bar/*.* pages and make routes unavailable.
Can pages be ignored on Next.js build without physically changing or removing page component files in the project?
You can configure the pageExtensions in the next.config.js.
// next.config.js
module.exports = {
pageExtensions: ["page.js"],
}
After configuring this, the only pages with *.page.js will be considered in the below given directory structure.
pages/
├── user
│ └── setting
│ ├── index.js
├── _app.page.js
├── _document.page.js
├── list.page.js
└── theme.ts
Custom file ignores patterns that are not supported yet. You can visit the PR created here, and the solution given here. This is the most satisfactory solution so far.
#Mathilda Here from Nextjs docs: it's necessary for all pages including _app, _document, etc.
https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions
Changing these values affects all Next.js pages, including the following:
- middleware.js
- pages/_document.js
- pages/_app.js
- pages/api/
For example, if you reconfigure .ts page extensions to .page.ts, you would need to rename pages like _app.page.ts.
Setup
I have a monorepo setup with the following file structure:
├── functions
│ ├── src
│ └── package.json
├── shared
| ├── dist
| ├── src
| └── package.json
├── frontend
| └── ...
└── firebase.json
Approach 1 (failed)
./shared is holding TypeScript classes shared among the ./backend and ./frontend. Ideally, I want to reference the shared lib from the functions/package.json using a symlink to avoid that I have to re-install after every change to my shared code (where most of the functionality resides).
However, this does not work (neither using link:, nor an absolute file: path, nor an relative file: path)
// functions/package.json
...
"dependencies": {
"shared": "file:/home/boern/Desktop/wd/monorepo/shared"
...
}
resulting into an error upon firebase deploy --only functions (error Package "shared" refers to a non-existing file '"home/boern/Desktop/wd/monorepo/shared"'). The library (despite being present in ./functions/node_modules/) was not transferred to the server?
Approach 2 (failed)
Also, setting "functions": {"ignore": []} in firebase.json did not help.
Approach 4 (works, but lacks requirement a) see Goal)
The only thing that DID work, was a proposal by adevine on Github:
// functions/package.json
...
"scripts": {
...
"preinstall": "if [ -d ../shared ]; then npm pack ../shared; fi"
},
"dependencies": {
"shared": "file:./bbshared-1.0.0.tgz"
...
}
Goal
Can someone point out a way to reference a local library in a way that a) ./functions always uses an up-to-date version during development and b) deployment using the stock Firebase CLI succeeds (and not, e.g. using firelink)? Or is this simply not supported yet?
Here's my workaround to make approach 4 work:
rm -rf ./node_modules
yarn cache clean # THIS IS IMPORTANT
yarn install
Run this from the ./functions folder
I'm running into an issue which seems similar to the one reported in https://github.com/sass/dart-sass/issues/284, but doesn't seem 'fixed' for me. I'm trying to follow the workflow described in https://getbootstrap.com/docs/4.1/getting-started/theming/ to import Bootstrap's SCSS source code.
Here is my (simplified) directory structure:
.
├── index.html
├── node_modules
│ ├── #mdi
│ └── bootstrap
├── package-lock.json
├── package.json
├── scss
│ └── peek-solutions2.scss
└── stylesheets
└── peek-solutions.css
I've installed Bootstrap using npm install bootstrap; my package.json contains the following dependencies:
{
"dependencies": {
"#mdi/font": "^2.2.43",
"bootstrap": "^4.1.1"
}
}
In peek-solutions2.scss, I've added the following line:
#import "../node_modules/bootstrap/scss/bootstrap";
I've tried the sass --watch command specifying input and output files in different directories (cf. https://sass-lang.com/guide), but I run into an import error:
Kurts-MacBook-Pro:peek-solutions2 kurtpeek$ sass --watch scss/peek-solutions2.scss:stylesheets/peek-solutions2.css
Error: Can't find stylesheet to import.
#import "functions";
^^^^^^^^^^^
../node_modules/bootstrap/scss/bootstrap.scss 8:9 #import
scss/peek-solutions2.scss 1:9 root stylesheet
Sass is watching for changes. Press Ctrl-C to stop.
It seems like this is a path issue; _functions.scss is in the same directory as bootstrap.scss in node_modules/bootstrap/scss, but it seems like the sass command is expecting it to be in my custom scss directory. How can I fix this?
just delete the dots in the beginning , you must write:
#import "node_modules/bootstrap/scss/bootstrap";
in your scss file
This happened to me because I was running ng build --prod within a folder other than the root project folder, and every other css import breaks.
The solution is to cd to the root folder.
I solved it by using an extra forward slash #import "//abstracts/variable";
I solved this issue by pointing the imports to the files directly, i.e:
#import 'style/components/palette';
to
#import 'style/components/_palette.scss';
For those using the sass NPM package and have their own NodeJS build script, make sure that you provide loadPaths as an options parameter in your compile or compileAsync method. For example:
import sass from 'sass';
// const sass = require('sass');
const build = async () => {
await sass.compileAsync('./src/index.scss',
{
sourceMap: true,
style: 'expanded',
loadPaths: ['./src']
}
);
};
Here ./src is where your main scss file resides, relative to your project directory. You might not need this configuration if the index file is in project root, but most people probably don't put their scss files there.
I finally worked around this problem by using Grunt instead of sass to compile and watch the SCSS files. After running npm install grunt --save-dev, npm install grunt-contrib-sass --save-dev, and npm install grunt-contrib-watch --save-dev, I added the following Gruntfile.js:
module.exports = function(grunt) {
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'),
sass: { // Task
dist: { // Target
files: { // Dictionary of files
'stylesheets/main.css': 'scss/main.scss', // 'destination': 'source'
}
}
},
watch: {
scripts: {
files: ['**/*.scss'],
tasks: ['sass'],
},
},
});
grunt.loadNpmTasks('grunt-contrib-sass');
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.registerTask('default', ['sass']);
};
Now if I run grunt watch, whenever I save scss/main.scss it gets compiled into stylesheets/main.css:
Kurts-MacBook-Pro:peek-solutions2 kurtpeek$ grunt watch
Running "watch" task
Waiting...
>> File "scss/main.scss" changed.
Running "sass:dist" (sass) task
Done.
Completed in 1.720s at Sun Jul 01 2018 14:41:11 GMT-0700 (PDT) - Waiting...
I installed the bootstrap old version which didn't add scss folder in bootstrap under my node module, so I uninstalled my bootstrap by the command npm uninstall bootstrap and installed it back by npm i bootstrap.
If, for example your index.scss file is in a directory called 'sass' e.g.
├── node_modules
├── sass
│ └── index.scss
then you should use this file path:
#import "../node_modules/bootstrap/scss/bootstrap";
I also got this error and I solved it just using the relative path, like this:
#import '../../node_modules/bootstrap/scss/bootstrap';
If you're using rails and trying to get production to work, you may have run the production command to build assets in your dev environment. For instance:
yarn build:css
or
sass ./app/assets/stylesheets/application.scss ./app/assets/builds/application.css --no-source-map --load-path=node_modules
Either way, Rails may be preferring the "built" assets over the dev ones. So you may already have fixed the issue with bootstrap and not know it! Remove your build directory:
rm -rf app/assets/builds
and your other asset files will be used.
I faced this issue in Laravel 9. Remove this symbol. ~
// Bootstrap
#import "bootstrap/scss/bootstrap";
In peek-solutions2.scss, remove the previous code and add this:
#import "node_modules/bootstrap/scss/bootstrap";
According to this github issue:
Dart Sass's command-line interface doesn't look for imports in any location that's not explicitly provided as a --load-path on the command line. Node Sass's CLI may behave differently.
Thus to get the a similar behaviour with node-sass use --load-path.
sass --load-path=./ src/scss/styles.scss dist/css/styles.css
This command will load the current dir and will resolve ./node_modules or a possible ./src.
I fixed this issue with updating sass version from 1.26.10 to 1.32.13.
Check where Bootstrap is in node_modules and add
#import "../node_modules/bootstrap/scss/bootstrap";
for it.
Try #import "~bootstrap/scss/bootstrap.scss";,
no forward slash after the tilde.
It can be routing issues, if you are on rails use this
#import "../../../node_modules/bootstrap/scss/bootstrap";
#import '../../../node_modules/bootstrap-icons/font/bootstrap-icons';
In my case, it was caused by the fact that my project was opened in a parent folder
root ⬅️ my vscode had this folder as a root
└── project ⬅️ should have been in this folder instead
├── node_modules
├── src
├── static
└── ...
In my case, I had a symlink to my C:\dev folder when the physical location was actually E:\dev. Changing directories from C:\dev\project to E:\dev\project and running the mix command fixed this for me
If you're using Aurelia, WebPack and SASS and you did an NPM install of bootstrap the import will be:
#import "../../node_modules/bootstrap/scss/bootstrap";
You simply need to cd into the root of your project folder. Two scenarios:
If you're deep inside the project, you need to run cd .. in the command line until you are in the root.
If you're outside of the project, you need to run cd [insert root folder here] and run your build again.
I really like eslint for es6 projects. Previously I've used it for new projects. Now I want to add it to a legacy project.
Fixing all pre-existing lint issues in one go is too much effort. Can I configure eslint (in .eslintrc.js) to only check files where I've explicitly enabled it with /* eslint-enable */ or similar?
ESLint has no default-disabled state that can be toggled by a file comment. You might be able to use .eslintignore for this purpose, however. You can ignore everything and then gradually whitelist files as you migrate them by using ! to un-ignore individual files. For example:
.
├── .eslintignore
├── .eslintrc.js
├── package.json
├── node_modules
│ └── ...
├── src
│ ├── index.js
│ └── module
│ └── foo.js
└── yarn.lock
Then your .eslintignore could look something like this:
# Start by ignoring everything by default
src/**/*.js
# Enable linting just for some files
!src/module/foo.js
In this case, src/index.js would be ignored, but it would lint src/module/foo.js.
I'm just trying to run a quick example with assemble. I've followed the instructions and run the installer, output is here
npm install assemble --save-dev
npm WARN package.json ocscommerce-frontend#0.1.0 No description
npm WARN package.json ocscommerce-frontend#0.1.0 No repository field.
npm WARN package.json ocscommerce-frontend#0.1.0 No README data
npm WARN package.json ocscommerce-frontend#0.1.0 No license field.
npm WARN engine get-stdin#5.0.1: wanted: {"node":">=0.12.0"} (current: {"node":"0.10.32","npm":"2.14.2"})
|
> fsevents#1.0.6 install /Users/Documents/Projects/OCSCommerce/prototype/web/themes/default/build/node_modules/assemble/node_modules/assemble-core/node_modules/base-tasks/node_modules/composer/node_modules/chokidar/node_modules/fsevents
> node-pre-gyp install --fallback-to-build
[fsevents] Success: "/Users/Documents/Projects/OCSCommerce/prototype/web/themes/default/build/node_modules/assemble/node_modules/assemble-core/node_modules/base-tasks/node_modules/composer/node_modules/chokidar/node_modules/fsevents/lib/binding/Release/node-v11-darwin-x64/fse.node" is installed via remote
assemble#0.7.0 node_modules/assemble
├── success-symbol#0.1.0
├── try-open#0.1.0
├── time-stamp#0.1.3
├── word-wrap#1.1.0
├── lazy-cache#1.0.3
├── base-cli#0.4.0
├── minimist#1.2.0
├── isobject#2.0.0 (isarray#0.0.1)
├── opn#3.0.3 (object-assign#4.0.1)
├── common-middleware#0.2.2 (mixin-deep#1.1.3)
├── engine-handlebars#0.8.0 (engine-utils#0.1.1, extend-shallow#2.0.1)
├── export-files#2.1.0 (lazy-cache#0.1.0)
├── ansi-colors#0.1.0 (lazy-cache#0.2.7, ansi-gray#0.1.1, ansi-yellow#0.1.1, ansi-magenta#0.1.1, ansi-bgwhite#0.1.1, ansi-bgyellow#0.1.1, ansi-blue#0.1.1, ansi-bold#0.1.1, ansi-cyan#0.1.1, ansi-bggreen#0.1.1, ansi-bgred#0.1.1, ansi-underline#0.1.1, ansi-grey#0.1.1, ansi-green#0.1.1, ansi-hidden#0.1.1, ansi-bgmagenta#0.1.1, ansi-italic#0.1.1, ansi-red#0.1.1, ansi-reset#0.1.1, ansi-black#0.1.1, ansi-dim#0.1.1, ansi-bgcyan#0.1.1, ansi-bgblue#0.1.1, ansi-white#0.1.1, ansi-inverse#0.1.1, ansi-bgblack#0.1.1, ansi-strikethrough#0.1.1)
├── composer-runtimes#0.7.0 (extend-shallow#2.0.1, ansi-gray#0.1.1, ansi-green#0.1.1, ansi-cyan#0.1.1, ansi-magenta#0.1.1, pretty-time#0.2.0)
├── base-config#0.3.3 (map-config#0.3.0, resolve-dir#0.1.0)
├── base-pipeline#0.1.4 (lazy-cache#0.2.7, extend-shallow#2.0.1, ansi-yellow#0.1.1, ansi-red#0.1.1, kind-of#2.0.1, stream-combiner#0.2.2, resolve-dir#0.1.0, through2#2.0.0)
├── base-argv#0.3.0 (arr-union#3.0.0, lazy-cache#0.2.7, extend-shallow#2.0.1, arrayify-compact#0.2.0, expand-args#0.3.1)
├── assemble-loader#0.2.6 (is-valid-glob#0.3.0, mixin-deep#1.1.3, has-glob#0.1.1, file-contents#0.2.4, load-templates#0.10.2)
├── base-store#0.3.2 (extend-shallow#2.0.1, project-name#0.2.3, data-store#0.12.1)
├── matched#0.4.1 (async-array-reduce#0.1.0, is-valid-glob#0.3.0, arr-union#3.0.0, extend-shallow#2.0.1, resolve-dir#0.1.0, glob#6.0.4, bluebird#3.1.1)
├── base-list#0.1.4 (arr-union#3.0.0, lazy-cache#0.2.7, base-tree#0.1.0, extend-shallow#2.0.1, union-value#0.2.1, question-cache#0.3.5)
├── base-questions#0.2.3 (get-value#2.0.2, for-own#0.1.3, mixin-deep#1.1.3, to-choices#0.1.1, set-value#0.3.2, common-questions#0.1.1, micromatch#2.3.7, question-store#0.3.2)
├── parser-front-matter#1.3.0 (lazy-cache#0.2.7, extend-shallow#2.0.1, gray-matter#2.0.2)
└── assemble-core#0.8.0 (assemble-render-file#0.3.1, assemble-streams#0.3.0, templates#0.9.5, assemble-fs#0.3.4, base-tasks#0.1.2)
Then I've added the task to my gruntfile:
grunt.loadNpmTasks('assemble' );
But every time I try to run it, I get a problem that the assemble module can't be found - this is from running grunt -v. All the other modules work by the way.
Registering "assemble" local Npm module tasks.
Reading /Users/Documents/Projects/OCSCommerce/prototype/web/themes/default/build/node_modules/assemble/package.json...OK
Parsing /Users/Documents/Projects/OCSCommerce/prototype/web/themes/default/build/node_modules/assemble/package.json...OK
>> Local Npm module "assemble" not found. Is it installed?
Loading "Gruntfile.js" tasks...OK
+ default, prototype, prototypeFull
Can anyone suggest what could be wrong?
Well the answer was sort of straightforward. The documentation page must be out of date (http://assemble.io/docs/Installation.html) - I found the info deep in the release notes of the git repository!
https://github.com/assemble/assemble/#release-history
"Assemble was completely re-written from the ground-up as a standalone node.js library and is no longer a grunt plugin. Grunt plugin support has been moved to grunt-assemble. Please see that repo for additional details."
It probably should have at least an update to the github readme if not the main documentation! Anyway, I installed grunt-assemble and it's working now....