Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to repackage for production #15

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

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