Feedback needed: simple:rest compat

Hi, I’ve started updating the packages from simple org.

They are basically around REST features.

To be compatible with Meteor 2.4 I’d to update a the connect NPM dependency and I also had to add new npm dependencies.

If you are using this package in your app I would like your feedback.

I don’t have any real app with this package, this is why your feedback is really important in this case.

Important changes:
simple:json-routes
simple:rest

If you are not getting what is Meteor Compat packages, read here.

This compat package was started because of this request.

3 Likes

Hi,

we are using the simple:json-routes packages and getting an error lately with the new version (2.3.0) and Meteor v2.4.

W20211012-11:15:17.931(2)? (STDERR) Tue, 12 Oct 2021 09:15:17 GMT body-parser deprecated undefined extended: provide extended option at packages/simple_json-routes.js:33:39

This can be reproduced by simply creating a new meteor 2.4 project and adding the simple:json-routes package.

meteor create --bare repro-meteor-simple-json-routes && cd repro-meteor-simple-json-routes
meteor add simple:json-routes
meteor run

The problematic line seems to be this one:

WebApp.connectHandlers.use(bodyParser.urlencoded({limit: '50mb'})); //Override default request size

Do you have any idea how to fix this?

Greetings.

I am having the same issue here.

I copied the json-routes in my packages folder and changed that line to:

WebApp.connectHandlers.use(bodyParser.urlencoded({limit: '50mb', extended: false})); //Override default request size

I’m not sure what the advantage of either true or false is exactly?

The extended option allows to choose between parsing the URL-encoded data with the querystring library (when false) or the qs library (when true). The “extended” syntax allows for rich objects and arrays to be encoded into the URL-encoded format, allowing for a JSON-like experience with URL-encoded.

Hi, could you open a PR here with your solution?

I believe it’s better to pass false to avoid depending on another library.

Thanks.

Thank you.

Published simple:json-routes@2.3.1.

2 Likes

Resurrecting this thread, because I suspect there will be users hitting a few road bumps with simple:json-routes and likely landing here for info.

We have managed to successfully upgrade to Meteor 3.0-beta.0. Among the many dependencies, we have simple:json-routes underpinning a REST API for managing user accounts.

We completely replaced connect with express in the locally forked package, so far with just one downside. With the connect router, the req.route property passed downstream was a string, representing the path. With the express router, req.route is an object, so to get the path you’d need to use req.route.path.

If anyone is interested, reply here and I can describe how to migrate a locally forked simple:json-routes, before a community supported version becomes available.

@filipenevola, I am happy to send a pull request to migrate this package and simple:rest-json-error-handler. We just need to discuss how to solve the req.route vs. req.route.path conundrum. Should we maintain compatibility, to minimise disruption as per the discussion in What impact does Webapp transition from connect to express have on community packages that use it?, or should we just accept that there will be a necessary disruption and just update the REAMDE with whatever breaking changes are identified?

4 Likes

I am interested as I am using simple:json-routes in my app

The best way is to keep whatever Express is doing, in this case, changing to an object.

Maybe you could create both versions in your PR, and if the user provides a string, you emit a warning so they know they are doing something that can break in future releases.

About changelog, we should add a CHANGELOG.md in the root dir so we document break changes.

And yes, a PR would be welcome :slight_smile:

Now, just to think outside of the migration discussion, I think we should adopt Express directly always. Then, part of these packages inside simple-rest would be unnecessary.

Al right, here it is Migrate `json-routes` to Meteor 3.0 by manueltimita · Pull Request #6 · meteor-compat/meteor-rest · GitHub.

It also includes a couple of updates to simple:rest-json-error-handler, which is often used together with json-routes.

CC @sabativi

Agreed. Best way going forward.

I added this as a TODO in README. I need to figure out how best to do it.

For now I added a section “Breaking changes” to the top of README.md in packages/json-routes, where it has a fair chance of being read. When I hit the wall with json-routes in the past, I went straight to the README in the root folder of meteor-rest, clicked the package name, and went to its readme.

If you don’t mind pushing CHANGELOG.md to the repo, just as a minimal template, I will fill it in from the READMEs of the packages.

Absolutely. It is a relief to not have to build myriad middlewares for every little thing, like it was the case with Connect.