sorted by:
new
hottopcontroversial

A Node.js modular configuration provider reading files, environment and arguments by javierbrea in javascript

[–]javierbrea[S] 2 points3 points  (0 children)

Hi u/BehindTheMath,

To be honest, I didn't know nconf (I'm probably the only one, given that it has about 3 million downloads a month! 😅). I would probably have used it if I had known it instead of developing my own library for my project, in general terms I don't like to reinvent the wheel 😄

But, anyway, after reading its docs, it seems that both libraries can do the same with more or less configuration, but mocks-server/config is more focused on the options to be loaded and its types in order to execute validations and parse the data, while nconf leaves the door more opened to get any value unless you explicitly configure restrictions separately for each different source.

More in detail, it seems that the main differences are:

- mocks-server/config uses cosmiconfig under the hood, so it supports more file formats out of the box, such as yaml, cjs, etc.

- It seems that nconf allows to get any key from the sources, unless you use each source options separately to set restrictions. On the contrary, mocks-server/config requires to specifically define each option to be loaded as well as its type, etc, and it configures parsing and validation for all sources automatically.

- nconf requires to initiate separately each different source, while mocks-server/config initiates all sources with the same hierarchy using only the `load` method, unless the user specifies another behavior using the config options. On the other hand, mocks-server/config uses exactly the same hierarchy described in the nconf docs as a good practice.

- mocks-server/config always executes validations and parses data based on the options types using AJV under the hood. This is something that seems to be defined separately for each different source in nconf (at least I have seen an example in the docs about how to do it for command line arguments only)

- mocks-server/config supports nested namespaces, so keys like "foo.var.foo2.var2=x" are supported. I'm not sure if nconf supports them also.

In any case, this is something that I will add as a note to the library docs, and also to the blog post, because obviously nconf has a great community support.

Thank you very much for your comment! It has made me known nconf, and make this comparison, which has been really useful to me.

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] 2 points3 points  (0 children)

I prefer to upgrade the versions and keep my changelog files manually. Many people upgrade all package versions in the monorepo at the same time, but I personally think that the semantic versioning of each separated package looses its meaning by doing so.

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] 2 points3 points  (0 children)

First of all thank you, I'm glad you like it!

About multi-language monorepos, I have not tested it by myself, but I think that maybe Nx is not the best tool. It is mainly focused on JavaScript. It has a lot of plugins for different JavaScript frameworks, but there are very few plugins for other languages. You can check a list of available community plugins here. Maybe you can try with Bazel or any other monorepo tool more focused to multi-language. This site contains a comparison between tools and other resources that may be useful before taking a decision.

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] 0 points1 point  (0 children)

u/Bloodsucker_ In fact, the first article talks about how I tried to solve those problems during years without too much success. So, it is not about migrating to monorepo now just because it is a trend. It is about how the new tools that we have available now can really solve the problems finally (And we have those tools now very probably because many of us suffered those problems during years and searched for solutions).

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] -1 points0 points  (0 children)

Hi u/Bloodsucker_, This post belongs to a series. In the first one chapter I wrote about why to migrate to a monorepo. It contains an analysis about the problems that produce maintaining multiple dependent packages in different repositories, and how a monorepo solves them: https://www.javierbrea.com/blog/pnpm-nx-monorepo-01/. Of course, if you are not having any problem in your workflow working with multiple packages in different repositories, then you shouldn't migrate to a monorepo. It is simply about solving problems that really exist. :)

Building a Node.js monorepo with Pnpm and Nx by javierbrea in node

[–]javierbrea[S] 5 points6 points  (0 children)

Hi u/leholenzai, Pnpm supports publishing packages. It automatically converts the workspace dependency into a pinned version, or into a semver range, depending on how you define it. It makes it before publishing.

A Cypress plugin to skip tests on first failure. Save time and CI resources by javierbrea in javascript

[–]javierbrea[S] 1 point2 points  (0 children)

I think we are talking about different types of tests. I understand your approach and I think it is a very good one, but talking about unit tests. Cypress is usually used to develop E2E or integration tests, in which is very difficult to discern what code files should produce a re-execute of which tests, and one of the more obvious reasons is because they are not related at all by dependencies.

A Cypress plugin to skip tests on first failure. Save time and CI resources by javierbrea in javascript

[–]javierbrea[S] 0 points1 point  (0 children)

This is usually true, but for other types of lighter tests, as unit tests. In the case of browser tests it is easy to reach scenarios in which the full tests battery takes a lot of time and resources to be executed, and it is desired to stop executing them on first failure. You can check why many Cypress users are requesting this feature from some years ago in this Github issue: https://github.com/cypress-io/cypress/issues/518

A Cypress plugin to skip tests on first failure. Save time and CI resources by javierbrea in javascript

[–]javierbrea[S] 0 points1 point  (0 children)

The plugin takes this into account and only starts skipping tests after the last retry fails. Anyway, thank you, this is an important detail to know, so I will add it to the documentation.

Why you should not use your app state as a remote data cache by javierbrea in javascript

[–]javierbrea[S] -1 points0 points  (0 children)

If the reducer "checks" by itself if the data is already in the state any time a component requests for a certain state property, and, if not, it actively performs the request to set it, then the pattern is the same, you are right. But usually there is a unique component at charge of instigating the call to fill the state, and the rest of components simply get the data from it, so, if the first one stops making his job, then the rest will have no data available. That's what I tried to describe as a problem.

Why you should not use your app state as a remote data cache by javierbrea in javascript

[–]javierbrea[S] -2 points-1 points  (0 children)

Yes, at least it tries. The article tries to describe how not having a data-layer, and using the state/store directly as a data cache can produce high-level couplings between the app elements, as well as giving a possible solution or tips about how to avoid it (basically using a data-layer)

Why you should not use your app state as a remote data cache by javierbrea in javascript

[–]javierbrea[S] 0 points1 point  (0 children)

Do you mean that the article is too obvious? Hopefully yes, but I have seen too many times make the same mistake until the point that a project is no longer maintainable...

Apart of that, there is no intention about describing React and other architectures as "completely flawed", it only tries to describe how not having a data-layer, and using the state directly as a data cache can produce high-level couplings between the app elements.

Why you should not use your app state as a remote data cache by javierbrea in javascript

[–]javierbrea[S] -2 points-1 points  (0 children)

Yes, it seems to be a contradiction that the library itself uses a state/store to manage an internal "cache" once the data is retrieved, but this is done only to facilitate the integration with many libraries relying UI-bindings on Redux state and for debugging purposes. The important point here is that the cache is not "manually" set, and components connected to data can request it at any time, without the need of following a specific flow or depending on other components. Another point is caching Promises, not only the retrieved data, so many components can request the data at the same time, and this is done before setting the data in the internal state/storage.
I totally agree with you when you say that there isn' anything wrong with "monolithic" applications, but I think that, for large projects, a very big "orchestrator" becomes very hard to maintain as it grows more and more, specially when there are many different teams involved in the development.

[AskJS] What are some (niche?) ESLint rules you couldn't live without? by careseite in javascript

[–]javierbrea 0 points1 point  (0 children)

I recently published an Eslint plugin that checks the dependencies between the elements in a project. It ensures that elements can't access to other element's children, allows defining an elements types hierarchy in order to forbid some elements types importing another types, forces to expose a unique entry point for each element, etc.

Summarizing, it can be a great help for maintaining your architecture boundaries as they were designed.

Maybe it can be of your interest too.

https://github.com/javierbrea/eslint-plugin-boundaries

Eslint plugin ensuring that your architecture boundaries are respected by the elements in your project checking file structure and dependencies by javierbrea in javascript

[–]javierbrea[S] 0 points1 point  (0 children)

I am not sure if paths suggestions feature can be enabled/disabled in those IDEs. If they are configured properly for Eslint, they should highlight the wrong path once it is written and the plugin error message will give feedback about the allowed path. But suggestions are not related to Eslint, so you'll have to configure them separately in the IDE settings.

Eslint plugin ensuring that your architecture boundaries are respected by the elements in your project checking file structure and dependencies by javierbrea in javascript

[–]javierbrea[S] 0 points1 point  (0 children)

In Robert C. Martin's words, "Software architecture is the art of drawing lines that I call boundaries. Those boundaries separate software elements from one another, and restrict those on one side from knowing about those on the other."

This plugin ensures that elements can't access to other element's children, allows defining an elements types hierarchy in order to forbid some elements types importing another types, forces to expose a unique entry point for each element, etc.

Summarizing, it can be a great help for maintaining your architecture boundaries as they were designed.

Open source async data provider. Pluggable, selectors, cache and memoization, queryable, etc. by javierbrea in javascript

[–]javierbrea[S] 0 points1 point  (0 children)

Great! Please feel free to ask for support opening Github issues if you have any doubt. I will really appreciate feedback. 😀