Skip to content

Conversation

@sullivanpt
Copy link
Contributor

Hello, forgive me for taking some liberties with your publishing structure. This change enables a second npm package that includes only the resources and dependencies needed for a production deployment to be published from this repository.

In this implementation, the original npm build and publish process is the same; however, after publishing mady, we can publish mady-production with the following

$ npm run build:production
$ cd production
$ npm version minor # or some other method to sync the package.json version number
$ npm publish

I've gone ahead and published the 2.11.1 release so I can consume it in my build pipeline. And I think I've given you publish access to npm as well.

I'll caveat this particular implementation is only one of many possible mechanisms we could use to publish a production mode dependency. The most straight-forward but intrusive of which would be to split the repo into several. I'm happy to rework this based on your feedback.

@guigrpa
Copy link
Owner

guigrpa commented Mar 21, 2018

Thanks for the proposal!

In fact, my mid-term plan is to reorganise mady into a monorepo using oao, with probably three parts:

  • mady: a wrapper, for backwards-compatibility (current applications depending just on mady would continue working)
  • mady-translator-tools: the translation application
  • mady-translate: the translate function (what you call mady-production)

I hope it won't take much time, but feel free to use mady-production for the time being!

@sullivanpt
Copy link
Contributor Author

sullivanpt commented Mar 21, 2018

I was so going to use mady-translate, but I changed my mind at the last minute; last minute decisions are always a bad idea, LOL. My own bias is against yarn, but you oao mono repo tool is really cool. (aside: I feel yarn served its purpose in forcing npm to improve and now it's just unnecessarily fragmenting the community, like node.io). update: actually I prefer 'mady-localize' for this package, since it is used for the localization step

Adding 'translate' in the name should help with discoverability too. If I can make another suggestion, when you republish to npm can you add 'i18n' somewhere in the name? It was several weeks of convoluted searching before I stumbled unto this project. Started with 'i18n' named projects, then when those didn't wow me I searched for 'local', 'global', then stumbled on 'messageformat' (only because I was reading angular2 code), and then finally landed here..

As long as I'm throwing advice your way, it'd be great if you could split the translator-tools into two packages: a stand-alone set of file parsers and writers, and then the web app itself. I can envision a need to have a set of CLI based tools for extraction and modifying the translation DB that is independent of the file watching web app. update: I'm finding I really need the tools separate from the UI, for example I want to be able to run "mady --recompile" as part of my build process, which currently has no option to run without also launching the UI

Looking forward to the repackaging and the increased flexibility. I've got a lot plans for your library . Seriously, thanks for your hard work here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants