In Bulma documentation (https://bulma.io/documentation/customize/with-node-sass/) it says to do an npm init and when prompted for an entry point, enter sass/mystyles.scss. I understand from previous post (What is "entry point" in npm init) that entry point during npm init should be your main.js file.
Why does Bulma documentation recommend making the custom scss file the entry point?
I'm keeping project entry point at main.js, but unsure of implications (if any).
TL;DR
It doesn't matter as long as your project isn't meant to be installed as a dependency.
The longer answer
To clearify what you read in the post about the NPM entry point:
The entry is used when users install your package from NPM and requires it. This means that if your entry is main.js,
const package = require("yourpackage");
will be the same as writing
const package = require("./node_modules/yourpackage/main");
Because you don't need this syntax inside your project, it doesn't affect anything, like compiling Sass, inside your project.
If the package is supposed to be published and installed as a dependency, however, you have to think about your entry point. If the project is primarily a Sass/SCSS package, I'd recommend setting the value to your main Sass/SCSS file, as there are Sass/SCSS processors that make use of the entry point.
That's also why the Bulma docs recommend setting the entry point to the Sass file. But in the end, it's your decision.
Related
I'm looking for a typescript definition file for the abstractions that are defined within the library ng-i18next (i18next for angularjs).
Looking through the project's page I didn't find anything. And when I go to issues -> ask, I landed here at SO.
I can't find it there neither using npm install ng-i18next plus exploring the file system with the downloaded files.
So basically no luck disregarding the "interface" used for searching a typescript definition file. Perhaps it doesn't exists.
Via web-gui
Via local-cli
Any data about the whereabout of this file will be appreciated.
Answer: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/ng-i18next/index.d.ts
Research: The repository https://github.com/i18next/ng-i18next has a link for typings, and it redirects to https://www.npmjs.com/package/typings, a deprecated repository that used to store typings, and it says in it's readme.md the following message:
Starting from TypeScript 2.0, users can install typings using npm install #types/<package>. These typings are coming from DefinitelyTyped.
So, in that repository (https://github.com/DefinitelyTyped/DefinitelyTyped) if you look for ng-i18next, it appears, nevertheless, its interface is just has options: any, so it doesn't give you any help.
I have a NPM package with a small user base, yesterday I created a new version and wanted to release it. I thought that I might as well make use of the new GitHub Packages and so I setup everything as GitHub suggested and released!
Now the problem is that I still have the old NPM page running on version 2.0.2 while everyone currently uses this as their dependency while the new GitHub package is on 2.0.4, Is there a way to 'synchronize' these two. Of course the GitHub Packages uses the <USER>/<PACKAGE> labeling while NPM just uses <NAME>.
Is the only thing I can do to publish on GitHub Packages and on NPM and just try to move users away from the NPM page?
If your publishing a public package, your better off just publishing it on NPM, as that is what most developers are used to.
I use GitHub Packages at work and the only advantage is that is effective free for hosting internal packages, as we are already paying for GitHub anyway. If it wasn’t for the zero price we wouldn’t be using it.
If you really want to force all your users to migrate to GitHub packages, and have to set up npm to work with it you could mark you old version npm deprecated and use that to point people to the new version.
https://docs.npmjs.com/cli/v6/commands/npm-deprecate
Here is another solution, but there is a catch.
Change your registry.npmjs.org package content to
index.js
export * from '#schotsl/my-package';
Now your registry.npmjs.org package is (almost) pointing to your npm.pkg.github.com package.
Only almost because any development directory for a project downstream of registry.npmjs.org/my-package, must configure the scope-to-server mapping for #schotsl/my-package to npm.pkg.github.com in a package manager config file.
In the case of package managers 'npm' and 'yarn' (v1) that can be done in
an .npmrc file at the same level as package.json.
The required .npmrc content is
#schotsl:registry=https://npm.pkg.github.com
# Github PAT token, packages:read authorization only ok
//npm.pkg.github.co/:_authToken="ghp_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
The first line is the scope to server mapping.
The second line is a Github personal authorization token (PAT) with at least package:read permission. It is actually pretty liberal. A PAT with package:read issued from any github account will allow read access to every github accounts packages.
For the 'yarn' v2 package, the .npmrc file does not work, and instead a couple of keys need to be set in .yarnrc.yml.
Unfortunately there is no way to set the scope-to-server mapping and the token inside the registry.npmjs.org/my-package package itself.
Putting the .npmrc file in there doesn't work, it is ignored. And that wouldn't be a good solution anyway, because not all package managers read .npmrc files.
That is the 'catch' - using npm.pkg.github.com packages requires package manager specific config settings to be made by every downstream developer.
In addition, what if two different upstream packages have colliding scope names, each mapping to a different server? The current config methodology fails in that case.
Feature Proposal not current behavior
Ideally, there would be a common interface agreed upon by all package managers inside package.json - and the scope-to-server mapping would be defined in the package that directly references the scope. For example, in the package.json of my-package on registry.npmjs.org
{
dependencies:{
"#schotsl/my-package":"1.0.0"
},
registries:{
"#schotsl/my-package":"https://npm.pkg.github.com",
},
auths:{
"https://npm.pkg.github.com":"ghp_XXXXXXXXXXXXXXXX",
},
}
Then downstream users would not need to config for each scope, and predictable (and risky) problems with scope name or package name collisions would not occur.
But that is not the way it is. Therefore Github Packages (npm.pkg.github.com) doesn't really seem to be a feasible way to provide public packages which may become dependencies of other public packages. No problem for private packages though.
I have a PHP project that uses Kirby CMS. I also use Gulp for building my assets. Now, I need to add a calculator on the homepage that is complex enough to justify the usage of Vue. How would I incorporate Vue in my project without introducing a ton of new tooling? All I want is a simple Single File Component basically. I have:
<div id="calculator"></div>
and I want the component to be rendered there. Nothing more.
After some consideration, I came up with the following options but found issues with each of them:
Use the Vue CLI for instant prototyping. That's the closest solution for my use case, but I can't easily develop the component. If I use vue serve, I get to see the component isolated in a new page. The issue lies in the fact the component isn't a part of my project's page. It's not affected by its stylesheets, layout, and other scripts. I can't know if it'll work properly once I build it and view it in my project. Running vue build on each change would be pretty painful and time consuming. Sadly, vue watch isn't a thing, which leads me to:
Creating a project and using Vue CLI Service. If I create a project, I'd be able to run vue-cli-service build --watch and have my component automatically refresh on each change of its source file. While developing the component, I simply make a change, wait for it to compile, and refresh my project in the browser to see the modified component in action. While that would work, it introduces a bunch of node_modules inside my project, along with a package.json. I feel that's too much for just a single component. It would pollute the project more than I'd like:
assets/
js/
build/
calculator/
dist/
node_modules/ # modules here
public/ # I don't need that
package.json # package here
package-lock.json
App.vue
scripts/
main.js
content/
site/
node_modules/ # modules here as well
panel/
package.json # package here as well
package-lock.json
index.php
I would basically have a project within a project.
Use vueify to compile the component with Browserify and Gulp (which I already use). While this appears OK, vueify is deprecated and not supported. Besides, I'd have to add a bunch of stuff to my gulpfile.js in order to use Babel + ESLint for the component.
How do I set up Vue in such a way that I'm able to develop a very simple component as a part of a larger project with as little friction as possible?
If anyone has dealt with a similar problem, how did they solve it?
I ended up using the second approach I mentioned in my question with one small twist - I initialized the Vue project in my main project. I merged them.
I opened the parent folder of my project in a terminal.
I ran vue create my-project where my-project was the actual folder name of my project. The CLI asked if it should overwrite the project or merge it. I chose merge.
After the project was created, my old package.json was overwritten and only had the Vue dependencies listed in it.
I reverted my old package.json and installed these packages: #vue/cli-plugin-babel, #vue/cli-service, vue-template-compiler, and vue.
I added the following npm script in my package.json:
"scripts": {
"calculator": "vue-cli-service build assets/js/calculator/main.js --watch --dest assets/js/calculator/build"
}
Result
My project's folder structure remained the same, except for a few new packages in node_modules. I put my component files in assets/js/calculator/. There, I have main.js which is the main component script, and build which is a folder containing the processed component.
I have:
<div id="calculator"></div>
in my page, and:
<script src="/assets/js/calculator/build/app.js"></script>
in the footer. When I open the page, the component is rendered correctly.
To modify the component, I simply run npm run calculator in a terminal, which spins up the CLI service. It monitors the main.js file and builds the component on each change. Once the build is complete (which happens in under a second), I refresh the page and the updated component is there.
Conclusion
I believe that's the smoothest way to handle this use case. It didn't bloat the project, all dependencies were listed, and the development experience is great. The part where my package.json got overwritten was a bit concerning, but other than that - it worked perfectly. If there's a better way to do this, please leave an answer!
This is probably not the answer you're looking for but if I were you I'd look into inline templates and x-templates as they seem well suited to your use case.
Also have a look at this blog post. It offers a nice write up about the different template authoring methods in Vue and their pros/cons.
Is there a way to remove plugins and its configuration with vue-cli3 in an existing project? For example I want to replace unit test plugin Mocha with Jest. I know how to add and invoke a new plugin but I cannot find how to remove one. Is it possible with vue-cli or do I need to do it manually?
I've asked about this (How does one uninstall a plugin? #2540) and it appears the current official advice is to issue an npm uninstall X.
I think you can just go to your package.json and remove the entry for the plugin/package,
delete the directory of your node_modules,
and then run.
npm install
Delete the vuetify stuff[1] from your package.json and then run:
npm prune
[1] Dependency vuetify and dev dependencies vue-cli-plugin-vuetify, vuetify-loader...
It looks like you need to do it manually, I cannot find anything in the docs or CLI help that mentions removal of plugins. It is slightly more complicated than #alexandre-canijo says though. Besides the package.json there may be some config in your project folder. Check the src/plugins folder, and main.js.
The documentation
You have to do it manually. It worked for me.
In my case, I just removed the plugin ("vue-cli-plugin-quasar": "^2.0.1",) from devDependencies in package.json and ran npm install.
With the new "vue ui" option, removing installed cli-plugins is supported now.
Under "Dependencies" (second tab on the left of vue ui) you'll find all plugins listed. And on the right of each plugin there is a little trash icon, which removes the respective plugin.
You still might get compile errors due to dead references in your sources, but those can be identified quickly with the provided log and error messages.
I am new, and when i first created my app based on the documentation using npm create-react-app i found it there were a lot of package included inside folder node_module when i code and i only use react and react DOM and etc from the basic.
node_modules
acorn
timer
ansi
and many more
I wonder if anyone can help my how to understand each use inside the node_module or where can i find the documentation for each use?
or how can i just reduce to what i want to use only to decrease the app size?
The answers are 2:
because you're using an automated scaffolding tool, which essentially does everything for you, and, you have just to code, it is supposed to locally deploy all the packages it needs to work (for example webpack is needed to bundle your code, babel to transpile it, ...
under node_modules you will find all the packages of the whole app. That's means you will find both your dependencies and the dependencies of your dependencies (this rule has some exceptions and you can find them in the npm documentation.
example:
// your code depends on A
var dependency = require('A');
// but then, inside your A dependency you can also find something similar to:
var b = require('B');
how can i just reduce to what i want to use only to decrease the app size?
You basically can't do it. They are all needed.
Most of the libraries that we pull from npm have dependencies. You may use only react and react-dom but there are react-scripts that require lots of stuff. I don't think that you have to worry about the size of the node_modules. That's not what you are suppose to ship in production.
If you want to see what are these all modules about you may open their folder and fine README.md file.