Include Meteor publishing in the default task?

[dandv]

Should the meteor publishing be included in the default task? If so, the wrapped package version number needs to be increased whenever the maintainer runs the task, or else Atmosphere will complain that the package version already exists.

Do people run Grunt default tasks a lot, so we'd end up with package v1.2.3_78?

[raix]

@dandv I'm not sure if it would be a problem - I might be missing something? eg. meteor add org:[email protected] this would use the latest patch or?

[dandv]

What I'm saying is that if we include meteor publish in the default grunt task, the dev might run that task many times during development, not just to release. (I've never used Grunt to develop a library so I don't quite know what the workflow is).

But if they do run the default task all the time, we don't want many _XXX versions of the package on Atmosphere. We only want the final release, the one they'll presumably push to GitHub and tag.

[raix]

_xxx releases are "subpatch" versions in order to keep track of the library version? so if its underscore 1.7.0 and a wraper package had some error its ok to add 1.7.0_1 (its the reason for it as I'm aware)

[splendido]

I'm not sure the default task is the right one where to place Meteor publish
For Semantic integration i pinged the maintainer which answered telling he's using gulp release and suggested to hook meteor publish into that very same task sequence.

His default task boils down to a simple gulp watch (see here)

I think it very depends on a developer's habit how to organize his task and we cannot propose to publish as a default action...

[zimme]

Maybe this gruntfile should have tasks like this

grunt meteor check-meteor
grunt meteor download
grunt meteor install
grunt meteor bump
grunt meteor publish
grunt meteor ...

I think this should be released as a grunt plugin. Then we can just update the respective repos by adding
the relevant tasks to the projects existing tasks.

[paralin]

+1 for plugin. I run grunt/gulp all the time in development.

On Sun, Nov 30, 2014, 9:00 AM Simon Fridlund [email protected]
wrote:

Maybe this gruntfile should have tasks like this

grunt meteor check-meteor
grunt meteor download
grunt meteor install
grunt meteor bump
grunt meteor publish
grunt meteor ...

I think this should be released as a grunt plugin. Then we can just update
the respective repo's by adding
the relevant tasks to the projects existing tasks.

Reply to this email directly or view it on GitHub
#1 (comment)
.

[dandv]

A problem with grunt check-meteor, download etc. is that the maintainer needs to run those tasks. How about adding meteor to the package.json install scripts?

  "scripts": {
    "preinstall": "# Make sure Meteor is installed, per https://meteor.com/install.",
    "install": "# The curl'ed script is safe; takes 2 minutes to read source & check.",
    "postinstall": "type meteor >/dev/null 2>&1 || { curl https://install.meteor.com/ | sh; }"
  }

[splendido]

what about extending the list of grunt tasks to be executed to release?
adding the meteor part at the end of the list should be fine.

This way when the maintainer do gulp release it will get also all the meteor tasks executed at the end of everything.

...this obviously assumes there's a specific task used for the release ;-)

EDIT: ok, this is a silly comment, feel free to remove it ;-)

[paralin]

Whatever you do make sure it doesn't install stuff on the person's computer
without their knowledge. That's a huge nono.

On Sun Nov 30 2014 at 2:01:56 PM Luca Mussi [email protected]
wrote:

what about extending the list of grunt tasks to be executed to release?
adding the meteor part at the end of the list should be fine.

This way when the maintainer do gulp release it will get also all the
meteor tasks executed at the end of everything.

...this obviously assumes there's a specific task used for the release ;-)

Reply to this email directly or view it on GitHub
#1 (comment)
.

[PEM--]

This should be a grunt plugin like this one: https://github.com/PEM--/grunt-phonegapsplash

Most grunt users are accustomed to plugins. What bothers me is:

• plugins are an opt-in situation.
• grunt plugins can't live in Meteor app space.

The same goes for gulp users (here's an example of a gulp project: https://github.com/PEM--/hellofamousgulped, still actively used).

I'm not sure how to proceed for the moment. Modifying the main grunt / gulp file of the package maintainer has to be as lightweight as possible. It will make the things clearer.

I'll have to think through it and come back on you with a clean proposal.

[zimme]

A problem with grunt check-meteor, download etc. is that the maintainer needs to run those tasks. How about adding meteor to the package.json install scripts?

grunt meteor check should at least be available to print warning about meteor not being installed when meteor grunt tasks are run. I'm more supportive of printing warnings when meteor isn't installed then just install it automagically as @paralin pointed out.

Creating this as a plugin will have the advantage to let the devs decide if they want to integrate the meteor tasks into their current tasks or if they wanna load them and use them manually to publish releases.

@PEM-- sure the plugins are opt-in, but we'll just opt it in for them when we submit PR's for their projects. Depending on the discussion with the dev, either we'll just grunt.loadNpmTasks and be done with it or we'll loadNpmTasks and add the meteor tasks to their release/publish/bump tasks.

...also the grunt meteor bump should read version from package.json/bower.json and the meteor package.js and compare to see if it should be a x.y.z_a version bump.

[dandv]

Once a 3rd party library is tested to work with Meteor, it's unlikely to break in the future, unless Meteor-specific work is done on it. That type of work, as well as the initial integration, will be tested by a Meteor dev. The original library author most of the time will not want to go through the Meteor testing process, so I think we should keep the meteor-test tasks separate, and move them to Travis.

Also, installing Meteor via package.json will be unnecessary for the original author in most situations; as for Meteor devs, they already have it.

Having Meteor install only when some explicit meteor command is issued seems best.

[splendido]

I agree it will be a security weakspot... in the sense that package maintainers might see this as even worse than having a bash/curl script to execute on their pc...
Thoughts?

[splendido]

also, the script can be executed automatically on new releases without having to check into `package.json.
See the documentation link on this post