Custom dependencies removed

#1

When I add a custom dependency to package.json it is removed when I start the app from radzen

0 Likes

Support firebase
#2

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?

0 Likes

#3

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?

0 Likes

#4

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.

0 Likes

#5

maybe package.json would be a good candidate to start OSSing the code generation .ejs templates(?)

0 Likes

#6

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.

0 Likes

#7

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

#8

@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.

  1. 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.
  2. 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.

0 Likes

#9

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

0 Likes

#10

How should I correctly add custom dependencies now, after you have added the code generation ignore list?

0 Likes

#11

You should add custom dependencies as any other node module - by running npm install --save <module name>

0 Likes

#12

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.

0 Likes

#13

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.

0 Likes