Tools (meteor update, testing) for packages-for-everything?


#1

Hi guys,

I just stumled about the packages-for-everything approach and like the idea of creating reusable components and organizing my code this way.

BUT having a look at the telescope example-project (https://github.com/TelescopeJS/Telescope)
it seems to me that I am stacking up my workload and I make my workflow more complex?

The project I am working on is quite complex and could need a good structure.
I am new to meteor & javascript and I am running this as a one-man-show
so i guess right now it is good for me to keep things simple. KISS.

My [newbie] assumptions are (please correct me if I am wrong)

  1. I’ll have to manually define each single file (including directory names) used within each package
  2. I’’ have to define package dependencies (including my standard set of standard-3rd-party-apps) in each package
  3. I’ll have to run meteor update manually for each package and maybe even update version-numbers of those dependency for each package
  4. I’ll end up with A LOT of packages (telescope has 37 packages to manage). Adding 1 package means adding another round of steps 1-3…
  5. I wonder: Will testing my packages work with velocity:jasmine?? This is really important for me

My questions to the experts are:
a) Would you recon this structure for a single-programmer working alone on a medium-complex project
b) Are there tools available to help me managing all those packages? (see steps 1-3)
c) Does testing work will with this structure? Right now I am sticking my head into velocity:jasmine
d) Will debugging work well?
e) Is there anything else to considerß

I’m really looking forward to your feedback

Thebarty


#2

Here is an expert view from @sewdn

http://meteorpatterns.com/Sewdn/project-builds


#3

a) I’m just starting a complex project with this approach and I like it. I feel my workflow and my code better structured.
b) Create a lib package with all 3rd party dependencies. All your other packages depend of this lib package. This way, you only need to update 3rd party versions in one package. Use packagecheck to see if there are updates for the 3rd party packages https://www.npmjs.com/package/packagecheck

More info here:



#4

Hi guys,

thanks a lot for your tips!!! I’ll give it a go!! :grinning:

One question concerning testing:
When I write velocity:jasmine tests and place them within the package - will they still be run by the standard velocity html-runner (the circle in the upper-right corner)?

The jasmine-docs talk about it but just mention a command line tool (https://velocity.readme.io/docs/jasmine-testing-a-meteor-package).

Any ideas? Maybe @Sanjo can give a quick hint?


#5

We removed html reporter as soon as we moved to package based architecture.
No need to test packages you are not changing at the moment.
We have no test as standard dependency in project.
All is handled by npm velocity-cli if I remember correctly the package name.


#6

Yes, by default the tests results are still outputted via the html-reporter. It’s basically the same as with app tests. The only bigger difference is that the package tests don’t run by default when you start your app. Instead you run velocity test-packages in a separate terminal. This starts a separate Meteor app instance where the tests are executed.


#7

@Sanjo: Thanks a lot for your tip. Unfortunatly I got problems getting this to work:

The problem is that html-reporter does NOT show the results for the package tests.

I have 2 Terminals running

  1. meteor (=port 3000)
  2. velocity test-packages --port 3001

This is the package config:

Package.onTest(function(api) {
  api.use('sanjo:jasmine@0.20.2');  // enable velocity:jasmine support

  // TEST FILES
  // .. Server
  api.addFiles([
    'tests/jasmine/server/integration/unit_test_spec.js',
  ], ['server']);

  // .. Client
  api.addFiles([
    'tests/jasmine/client/integration/unit_test_spec.js',
  ], ['client']);

  // .. Shared (= Client+Server)
  api.addFiles([
    'tests/jasmine/shared/integration/shared_test_spec.js',
  ], ['client', 'server']);
});

Any ideas how to get this running? :fearful:


#8

Are you looking at the html-reporter at http://localhost:3001? See if there is an error in the browser console.


#9

@Sanjo: Thanks for the info.

I got it wrong and expected the html-reporter to show the infos right within localhost:3000 - included together with the app-tests. But I guess I have to check the package-tests in a different window.

It would be really cool though to have them appear within the localhost:3000 html-reporter :yum: