When I add a custom dependency to package.json it is removed when I start the app from radzen
Indeed package.json is regenerated when you run a Radzen application. We have to do that for various reasons - version upgrades, add/remove dependencies. Maybe we can add support for excluding files from code generation. Say a file similar to .gitignore which contains glob expressions for files that should not be overwritten by Radzen.
For example a file called .radzenignore which contains package.json would prevent any rewriting. Would that work?
That will help, but I suppose in that case, if there is an radzen upgrade and e.g. the angular version is updated to a newer version, the developer has to do this manual?
Or another suggestion like the typescript compiler setting file.
tsc merge the settings.
For example, if you specify a tsconfig.xxx.json in a folder, the common tsconfig.json is merged with this file.
for example:
{
“extends”: “…/tsconfig.json”,
“compilerOptions”: {
“outDir”: “…/out-tsc/app”,
“baseUrl”: “./”,
“module”: “es6”,
“types”: []
},
“exclude”: [
“test.ts”,
“**/*.spec.ts”
]
}
where “extends”: “…/tsconfig.json” tells the tsc to merge this settings with the common tsconfig.json file
Is that an option?
That will help, but I suppose in that case, if there is an radzen upgrade and e.g. the angular version is updated to a newer version, the developer has to do this manual?
Yes, the upgrade would be manual in that case.
Or another suggestion like the typescript compiler setting file.
tsc merge the settings.
Unfortunately I don’t think package.json supports merging (would have been perfect if it did). I see a closed issue about that but not a working solution.
A different solution would be to support a list of custom NPM dependencies which the developer can set from the Radzen app settings. The only downside is that npm install should then be run manually every time the Radzen dependencies change.
maybe package.json would be a good candidate to start OSSing the code generation .ejs templates(?)
Even then the package.json would have to be manually upgraded every time the built-in is. We need some kind of package.json merge ideally.
Maybe you’re overthinking things. You generate the package.json yourself at the moment.
So wouldn’t it be possible to store the general content in a file: ‘package.general.json’ and custom things in ‘package.custom.json’ and regenerate the resulting package.json using a merge of those files.
1 Like
@DeBiese it would be possible but the implementation is similar to what general purpose package.json merge would be. The only hard part is how to resolve version conflicts and deleted dependencies.
- The developer depends on package A with version 1.0.0 whereas Radzen updates package A to 1.1.0. In this case it is not clear what a merge should do. In both cases there is a risk of build or runtime errors.
- The developer adds a custom dependency A. Radzen removes a package B which is for some reason no longer needed. Package B however remains in the package.json file and Radzen thinks it is a custom dependency (because it no longer exists in the template package.json). As a result package B stays forever (unless the developer manually deletes it). Not as big of an issue as the former.
One drawback of having package.general.json and package.cusom.json is that by default npm install --save updates package.json and the developer should manually update package.custom.json with the new additions.
If we can invent some sensible way of resolving conflicts it would be easy to implement seamless package.json merge.
I think you should make a difference between the packages radzen needs and the custom packages a developer adds.
So the radzen dependencies are always the versions you defined. In that case you can guarantee that radzen is working as expected.
And the custom packages are merged on code generation with the package.json
Of course, a custom package can have a dependency that is higher than the one that is used by radzen. In that case it would be nice if radzen is warning for those dependencies (like npm and yarn do)
Maybe you can also look at the following project to add a custom ui to manage npm packages https://www.npmjs.com/package/npm-gui
How should I correctly add custom dependencies now, after you have added the code generation ignore list?
You should add custom dependencies as any other node module - by running npm install --save <module name>
Is this still the correct way to add custom dependencies in client? When I do so, it wipes out node modules and nothing works. I have to reinstall RadZen.
Yes it is. Your Radzen application was probably running at the time which caused npm install to wipe out the internal node_modules directory that Radzen symlinks by default when you run an application.
If Radzen needs specific modules to be present in order to function, then it should check for those modules in the existing dependencies list and add them if it does not find them.
Packages.json is a text file that can be read into an object, inspected, "merged", and saved in less than 50 lines of code in several programming languages. A special merge function or module produced by a third party is not needed.
Deleting any other existing dependency records seems like its actually more code/work. The current operation is a big interruption to user productivity because it is doing an unexpected thing, and not telling anyone about it, and we are left to find it out when ng build stops working at random times in the development cycle.
This cost about 4 man-hours of time to diagnose the other day, and its going to be a repeating cost to fix it every time it happens. Please just fix it.
If Radzen needs specific modules to be present in order to function, then it should check for those modules in the existing dependencies list and add them if it does not find them.
Those modules are required by Radzen and not by the produced application. That's why they aren't a part of the package.json of that application. We can indeed check if those modules are present though to detect corruption. Will investigate that further.
Packages.json is a text file that can be read into an object, inspected, "merged", and saved in less than 50 lines of code in several programming languages. A special merge function or module produced by a third party is not needed.
Radzen is already merging the package.json file and custom dependencies shouldn't be lost. However if you run npm install while there is a symlinked node_modules directory it will corrupt the Radzen installation.
If we add something like webpack to the package.json, and then open the project in the Radzen, and inspect the package.json file again, webpack will be gone. I'm pretty sure that something is trying to install/restore packages as it will usually display an EPERM about the lock file at the same time. My associate has the before and after json files to share, did you want to use this issue (the title is correct) or open another one?
We reproduced the described problem and will work on a possible solution next week. As a temporary workaround you can add the package.json file to the code generation ignore list.