Wappler rewrites package.json "script"

Version: 7, Beta 17
Node JS
MacOS

To be honest this could also affect previous versions, but we only just added this so its hard to tell.

Issue

We changed the "scripts" directive in our package.json file to load an additional error logging file. Each time we open Wappler it tries to overwrite the contents - see screenshot.

Expected Behaviour

This shouldn't happen. Wappler should edit the file once when the project starts (and if modules are added by Wappler using npm). It shouldn't be trying to overwrite the contents that users have manually set / overwritten.

Bump

Bump again! Any thoughts here @George @Teodor ?

Bump again!! @George @Teodor ?

It's not version specific - it's been that way for quite a while.

As your needs evolve, you'll probably want to take more control of the build cycle outside of Wappler.

Well we run currently NodeJS with the parameters as required for running our server connect. So we don’t have any additional options for it.

Also we run it with the options we know it works. So if you start adding some options we aren’t aware of that break the whole server how do we what broke it.

So for now we don’t support additional options and I don’t see many cases that will be useful without breaking things.

So will turn this into feature request to see how many other people are dealing with those.

Also there are other ways btw to integrate error reporting and specifically Sentry that are much better than simple command line parameter.

1 Like

Appreciate the reply George. Don't get me wrong, what you've put together with Wappler is downright awesome and I appreciate it, and I also understand that you need to also support the basic user.

However, I do feel that in these situations where users want to do things a little bit outside of the scope of what the normal user would do but still want to use Wappler, they should be able to do so, especially when a file like package.json isn't a Wappler product.

Of course, it's also then fair that as a consequence, if the user breaks something, then they should also not get the normal support. I guess it would be no different to implementing another framework and then making edits outside of the what is "supported".

For example, while they are great, we don't use any of the Wappler target deployment options as they don't suit our needs. So we run our own CI/CD, and so therefore we don't expect any support for it from the Wappler team.

But taken onboard, we will have a look at some other error reporting options in the meantime.

Hi @George I've done a bit of investigating on your recommended Sentry solution, both in the community forum and also the Sentry docs site.

The Sentry docs (Node.js | Sentry for Node.js) state that Sentry.init should be initialised as early as possible before requiring other modules.

How would you propose this should be handled, given server.js is frequently updated (so us adding to the code will be a pain) and based on your previous comment to not support manual changes to the "script" directive in package.json (which is how we included it before anything else)?

I understand that from this post that you can implement export.before / after, but a quick test confirms that doing it this way initialises Sentry much later after a lot the requires in server.js including after app = express() when the routes are processed.

Any help would be appreciated.

I may be misunderstanding this thread but if the only issue is adding an entry to package.json, could you not write a custom module (doesnt actually need to do anything) and declare the required dependency within the hjson of the custom module.
That would force wappler to add and keep it in package.json?

Thank for the reply Hyperbytes, from what I understand, custom modules that are installed with npm only get loaded when they are required by a script that is included just before or after the routes are processed - which would be quite late in the server.js based on the sentry instructions to include it as early as possible. Hope that makes sense.

The server.js script starts by loading a lot of files written by the Wappler team for config, sockets, express, etc, then it sets up the app object, then processes the routes and middleware which is when any custom module files are processed.

I might have that understanding wrong, so would good to get some other input?

The routes are loaded very early and you can have a custom module run just before that. The only code before the routes are the debug module, loading the config and the rateLimiter if you have that enabled. All the other modules like for database, cors, cron etc. are loaded later.