I have used the theme-generator to create a fresh theme.
Now I've created a second theme in the same directory and tried to set it's base/parent theme using gulp extend as explained on these pages:
https://github.com/liferay/liferay-theme-tasks
https://dev.liferay.com/de/develop/reference/-/knowledge_base/7-0/theme-gulp-tasks
After running the command and choosing option 1) to extend the Base Theme , I get the following options:
Styled
Unstyled
Search globally installed npm modules (development purposes only)
Search npm registry (published modules)
No matter if I choose 3) or 4) I cannot find the theme package.
Do I really have to publish the theme to npm to be able to find it?
Following this explanation I could achieve it using npm link:
npm link
Excerpt:
npm link: symbolic links to the rescue Fortunately npm provides a tool
to avoid this tedium. And it's easy to use. But there's a catch.
Here's how it's supposed to work:
cd to src/appy
Run "npm link". This creates a symbolic link from a global folder to the src/appy folder.
cd to src/mysite
Run "npm link appy". This links "node_modules/appy" in this particular project to the global folder, so that "require" calls
looking for appy wind up loading it from your development folder,
src/appy.
Mission accomplished... almost. If you installed Node in a typical
way, using MacPorts or Ubuntu's apt-get, then npm's "global" folders
are probably in a location shared system-wide, like /opt/local/npm or
/usr/lib/npm. And this is not good, because it means those "npm link"
commands are going to fail unless you run them as root.
EDIT: I was wrong to make a npm package out of it when you can also just require it locally. Even relative paths work. Example:
"dependencies": {
"my-liferay-theme": "file:../My-Liferay-theme",
}
Related
I am working on an npm package that includes an example directory to run/test the actual package. In the example directory, I have included back the parent package using "file:..".
This works fine when developing and making frequent changes to the parent package, but if I want to use the example as a stand-alone app, I would need to point to the actual npm package.
Is there a way to have "2 configs" in the same package.json:
one that points to `"file:.." for local development
one that points to the npm package to use as a stand-alone app
This would avoid duplicating the example directory
You could do this with lerna which is a mono-repository CLI tool.
First of all, you would have to define multiple projects within the same repository. Lerna calls these projects "packages" and stores all of them within a /packages folder.
package.json
/packages
/my1stPackage
package.json
/my2ndPackage
package.json
Lerna has all kind of optimizations, which I won't dive in too deep here. But there are a couple of basics:
to initially install all dependencies of all repos, run lerna bootstrap --hoist.
You can still run npm run ... as before, but those refer to your root package.json file. To run npm scripts for specific sub-package you should run lerna run <args> -scope=<packageName>. (e.g. lerna run build --scope=my1stPackage)
You can add shortcuts for this in the root /package.json script section.
"scripts": {
"setup": "lerna bootstrap --hoist",
"build:my1stPackage": "lerna run build --scope=my1stPackage"
}
What will interest you most, is that sibling packages can just reference each other from their specific package.json to include each other as dependencies.
So, let's assume that my1stPackage uses my2ndPackage. Inside the package.json file of my1stPackage there would be something like
"dependencies": {
...
"my2ndPackage": "^0.0.1"
}
The my2ndPackage could actually be a package which is published in npm. However (!) while developing locally, lerna will add a symbolic link inside the /packages/my1stPackage/node_modules/my2ndPackage, which points to the folder of /packages/my2ndPackage. (And that really does work on all relevant operating systems.)
You package.json looks the same for local development as it does for people who download your package through npm. However, it's your lerna setup that fixes this with this symbol link.
I found two potential ways to do this:
npm link : https://docs.npmjs.com/cli/v7/commands/npm-link/
npm workspaces : https://docs.npmjs.com/cli/v7/using-npm/workspaces
But in my specific case, there are packages that can conflict between the parent and child (example) packages.
I couldn't find a robust way to make it work and decided that the simpler approach would be to simply create a separate repository that would contain a stand-alone version of the example directory and a script that can keep it up to date with the "master example" in the original repository. This way development stays fast and the "example copy" is easy to keep up to date without duplicating code.
I want to try and make some changes to a package published in npm? (I've suggest some changes as an issue but I think they are simple enough for me to attempt them).
https://www.npmjs.com/package/bt-presence#contributing--modifying
The author supplies some information on how to modify the package, but not really enough for someone doing it for the first time.
Where should I clone the GitHub repo to? The folder where the package is installed? I tried it in my home folder and that would not build (unmodified).
The command npm run build - where is this run from? The root folder of the package where the package.json is?
Will I need to modify the package.json?
In general what is the best way to develop something like this for npm? I've worked on packages before but they were simply Javascript.
If you want to work on the bt-presence package in isolation, you can put the cloned repository anywhere. If you want to use your modified version of bt-presence in combination with an application, my recommended approach is to register bt-presence as a dependency in the application's package.json file with the version set to a relative path to your bt-presence repository; then running npm install in the application will make a symlink from node_modules/bt-presence in the application to your bt-presence repository.
npm run build should indeed be run from the root folder that contains the package.json of bt-presence.
If you just want to change the code of bt-presence, you won't need to modify its package.json. You would only modify the package.json if you need to change any of the settings in there, e.g, if you need to add additional dependencies to your version of bt-presence.
None of the above is really specific to TypeScript. (Some JavaScript packages have build processes too if they need to transform or package the JavaScript files in some way.)
Always feel stupid asking here because people are always confused with my questions, or I have a dumb problem, but, I'm working on a program in node.js and the text editor I'm using (NP++) doesn't seem to like to save files in the system32 directoy, (The directory where my modules are), and that is where my script is as well. (So I have .../.../node_modules/(modules) and .../.../node_modules/script.js) this becomes a pain when I want to edit the script, I have to clone the script to my desktop, then edit it, then overwrite the one in the node_modules directory. I tried saving the script to my desktop and running it, but it just gives me an error of module not found. (In my script I have the modules as var example = require('example.js')) Is there any way I can get it to get the modules from the node_modules directory, while keeping the script file somewhere easily accessible and editable? (i.e desktop?) (Sorry if this is confusing, not the best at these kind of things)
I'm not 100% sure that this is what's happening because I haven't used npm on Windows, but it sounds to me like you're installing your dependencies globally using npm -g. The more proper way to use Node is to install your dependencies locally, using npm without the -g flag. That way your dependencies get installed in your current working directory.
For example, let's say you've saved your project in a directory on your Desktop, and your script uses require("lodash"). If you cd to your directory and run npm install lodash, then the lodash module will be available to your script.
I have a project setup that is as follows:
workspace
└cache
└node_modules
└gulp (and gulp-plugins, express etc.)
└nodejs
└node.exe
└project1
└gulpfile.js
└project2
└gulpfile.js
Now I want to execute the gulpfile in the project directories:
set NODE_PATH='C:\workspace\cache\node_modules\'
cd C:\workspace\project1\
C:\workspace\nodejs\node.exe C:\workspace\cache\node_modules\gulp\bin\gulp.js watch
and I get the following output:
[12:06:04] Local gulp not found in C:\workspace\project1
[12:06:04] Try running: npm install gulp
In both project folders the gulpfile is similar and uses a similar set of plugins. I'd really like to have the dependencies only once (because potentially I have up to 25 projects sharing the same node_modules).
Is this setup possible, or does the seperate project directories need to have their own node_modules folders?
Gulp requires you to have both a global installation as well as a local one. So you need to have your Gulp relatively to your Gulpfile. If your package.json would be located in workspace and your node_modules would be in workspace/node_modules everything would work fine because of Node's search tree, but if you can't move them, the only way to make it work is to "fake" the node_modules folder.
You can do this by creating a symbolic link.
Here's on Unix/Linux/Mac:
ln -s ../cache/node_modules node_modules
Here's on Windows
mklink /D node_modules ../cache/node_modules
(the latter one might work different, I'm not on a Win machine)
You could also try pkglink
From description:
Space saving Node.js package hard linker. pkglink locates common JavaScript/Node.js packages from your node_modules directories and hard links the package files so they share disk space.
Edit: ddprt
On Windows
mklink /D node_modules "C:/fullPATH/cache/node_modules"
you could always use the '-g' parameter with npm install 'package-name', so as to make the module available globally to access across different projects.
See the following links
what does the "-g" flag do in the command "npm install -g <something>"?
How do I install a module globally using npm?
https://docs.npmjs.com/files/folders
Packages are dropped into the node_modules folder under the prefix. When installing locally, this means that you can require("packagename") to load its main module, or require("packagename/lib/path/to/sub/module") to load other modules.
Global installs on Unix systems go to {prefix}/lib/node_modules.
Global installs on Windows go to {prefix}/node_modules (that is, no
lib folder.)
Scoped packages are installed the same way, except they are grouped
together in a sub-folder of the relevant node_modules folder with the
name of that scope prefix by the # symbol, e.g. npm install
#myorg/package would place the package in
{prefix}/node_modules/#myorg/package.
Does anyone know how to configure location of global repository?
My global repo is somewhere under $HOMEDRIVE/$HOMEPATH/blahblahblah
and all my packages are being installed under that place fopr global reference
but I want to park it somewhere specific and secret like the docroot of my appserver ? so I can operate demos and proof-of-concepts and prototypes ands show them off
can you tell me how I can configure the path to my global repository? I am on windows7 which is thoroughly supported and chmod chown issues are not as prevalent on linux
is this directory anchor controlled by a designated variable within NPM?
is this variable ever referenced by javascript modules indiscriminantly? i would hope not
I assume this variable is within the NPM tool itself.
what about bower... would bower operate the same configurable? or is bower a different animal and place.
is bower a subset of npm? anmd of so does it operate the same configuration as npm?
thank you
See the npm docs about the folders. It states that the global modules are installed under a configured prefix. You can get it from the npm config comand:
npm config get prefix
And you may change it with a similar command:
npm config set prefix /path/to/my/global/folder
However, modules are usually installed globally if want to use some command line command they provide. For using in some node.js application, prefer to install them locally. If you still want to use the globally installed modules inside the application, you should use the link command (though I'm not sure if it works in a Windows environment).
Bower is another thing completely. Looking at the api documentation, you will see that there is no option to install modules globally (which makes sense, as Bower is intended for front-end dependencies).
You could change the default folder using the directory parameter of your .bowerrc file (see the documentation). This way you would be able to set all projects to use the same folder, but notice that's not the way it's intended to use and you would need to set it in all projects.
npm config set registry <registry url>
once this command is run, check in ~/.npmrc, it must show your changes.