Smalltalk › Amber Smalltalk

0.12 -> 0.13 migration guide

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 2 messages Options
Herby Vojčík
Reply | Threaded
Open this post in threaded view
♦
♦
|

0.12 -> 0.13 migration guide

Herby Vojčík
Hello!

The migration guide between 0.12 and 0.13 must be written.
It would be nice if someone took this up, I try to outline the main
items here:

0.12 project layout
----

index.html with:
   <head>
   <script src="path_to_amber/support/requirejs/require.min.js"></script>
   <script src="path_to_amber/support/amber.js"></script>
   </head>
   <body>
   <script>
     require.config({paths: {
       /* project mappings */
       /* library mappings */
     });
     require(["amber/devel|deploy" /*, packages */, function(smalltalk){
       smalltalk.initialize({/*options*/});
       smalltalk.globals.SomeClass._someStartMethod();
       // if older, previous line may lack .globalsk
     });
   </script>
   // if code outside needs to call smalltalk, it must be
   // require('amber/helpers').globals.SomeClass._aMethod();
   </body>

src directory (or js/st directory if older) with app code
libraries in bower_components (or custom layout)
tooling (if used) support libs in node_modules, only needed for development

Gruntfile.js may be missing, if present, if just contains tasks to
recompile / test, written by hand.

0.13 default (`amber init`-created) project layout
----

index.html with:
   <head>
   <script src="the.js"></script>
   </head>
   <body>
   <script>
     require(["app", function(amber){
       amber.initialize({/*options*/});
       amber.globals.SomeClass._someStartMethod();
     });
   </script>
   // if code outside needs to call smalltalk, it must be
   // require('amber/helpers').globals.SomeClass._aMethod();
   </body>

src directory with app code

devel.js and deploy.js files with sets of packages to load

config.js file with generated amd mappings
the.js file with generated loader code (just loader in devel mode, whole
app packaged in one file in deploy mode)

local.amd.json file with project mappings

foolib.amd.json files with library mappings (per library folder)

libraries in bower_components (or custom layout)
tooling support libs in node_modules, only needed for development

Gruntfile.js with tasks for:
   - recompilation
   - running tests
   - computing amd config from *.amd.json (regenerates config.js)
   - switching between devel / deploy mode (regenerates config.js, then
the.js)

Migration process
----

As can be derived from differences above, migration steps involve:

  - Renaming 'smalltalk' to 'amber' in loader callback (shift in
convention, not crucial).
  - Adding .globals when accessing smalltalk globals.
  - Moving app-level amd mapping into local.amd.json file.
  - Specifying external libraries amd mapping (unless they already
contain local.amd.json, which may be the case for amber-specific
libraries; amber core as well as helios do have one) in libdir.amd.json
file(s).
  - Listing production package set in deploy.js.
  - Listing development package set in devel.js.
  - Adding bookkeeping tasks into Gruntfile.js (and installing their npm
dependencies with --save-dev), including:
  - Including requirejs as npm devDependency (npm install requirejs
--save-dev).
  - Getting familar with different chores:
    - when new production package added, update deploy.js (not
index.html) and Gruntfile.js (to include it in compilation and testing)
    - when new test package added, update devel.js (not index.html) and
Gruntfile.js (to include it in compilation and testing)*
    - when new external library added, add its mapping as
libdir.amd.json (not into index.html; libdir being name of directory
when lib was installed), add it to deploy.js or devel.js (where it
belongs), and rerun 'grunt devel' (to regenerate config.js and the.js).

  - When developing a library, not an app, there is no need to have two
sets and deploy / devel modes, as one is _always_ in devel mode with
library (only app then includes it then minifies it into the app
all-in-one file). So the above things may be simplifies by having just
one load set.
  - Also, when developing library, it is crucial to select good
namespace to be present in local.amd.json, as client of the library will
automatically get mappings in library's local.amd.json integrated in
their apps.

* I know there's two space problem here. Hopefully future brings a
solution where there will only be one list, not three.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Hannes Hirzel
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: 0.12 -> 0.13 migration guide

Hannes Hirzel
Copied to https://github.com/amber-smalltalk/amber/wiki/Migration-from-0.12-to-0.13

Still needs editing.

On 10/5/14, Herby Vojčík <[hidden email]> wrote:

> Hello!
>
> The migration guide between 0.12 and 0.13 must be written.
> It would be nice if someone took this up, I try to outline the main
> items here:
>
> 0.12 project layout
> ----
>
> index.html with:
>    <head>
>    <script src="path_to_amber/support/requirejs/require.min.js"></script>
>    <script src="path_to_amber/support/amber.js"></script>
>    </head>
>    <body>
>    <script>
>      require.config({paths: {
>        /* project mappings */
>        /* library mappings */
>      });
>      require(["amber/devel|deploy" /*, packages */, function(smalltalk){
>        smalltalk.initialize({/*options*/});
>        smalltalk.globals.SomeClass._someStartMethod();
>        // if older, previous line may lack .globalsk
>      });
>    </script>
>    // if code outside needs to call smalltalk, it must be
>    // require('amber/helpers').globals.SomeClass._aMethod();
>    </body>
>
> src directory (or js/st directory if older) with app code
> libraries in bower_components (or custom layout)
> tooling (if used) support libs in node_modules, only needed for development
>
> Gruntfile.js may be missing, if present, if just contains tasks to
> recompile / test, written by hand.
>
> 0.13 default (`amber init`-created) project layout
> ----
>
> index.html with:
>    <head>
>    <script src="the.js"></script>
>    </head>
>    <body>
>    <script>
>      require(["app", function(amber){
>        amber.initialize({/*options*/});
>        amber.globals.SomeClass._someStartMethod();
>      });
>    </script>
>    // if code outside needs to call smalltalk, it must be
>    // require('amber/helpers').globals.SomeClass._aMethod();
>    </body>
>
> src directory with app code
>
> devel.js and deploy.js files with sets of packages to load
>
> config.js file with generated amd mappings
> the.js file with generated loader code (just loader in devel mode, whole
> app packaged in one file in deploy mode)
>
> local.amd.json file with project mappings
>
> foolib.amd.json files with library mappings (per library folder)
>
> libraries in bower_components (or custom layout)
> tooling support libs in node_modules, only needed for development
>
> Gruntfile.js with tasks for:
>    - recompilation
>    - running tests
>    - computing amd config from *.amd.json (regenerates config.js)
>    - switching between devel / deploy mode (regenerates config.js, then
> the.js)
>
> Migration process
> ----
>
> As can be derived from differences above, migration steps involve:
>
>   - Renaming 'smalltalk' to 'amber' in loader callback (shift in
> convention, not crucial).
>   - Adding .globals when accessing smalltalk globals.
>   - Moving app-level amd mapping into local.amd.json file.
>   - Specifying external libraries amd mapping (unless they already
> contain local.amd.json, which may be the case for amber-specific
> libraries; amber core as well as helios do have one) in libdir.amd.json
> file(s).
>   - Listing production package set in deploy.js.
>   - Listing development package set in devel.js.
>   - Adding bookkeeping tasks into Gruntfile.js (and installing their npm
> dependencies with --save-dev), including:
>   - Including requirejs as npm devDependency (npm install requirejs
> --save-dev).
>   - Getting familar with different chores:
>     - when new production package added, update deploy.js (not
> index.html) and Gruntfile.js (to include it in compilation and testing)
>     - when new test package added, update devel.js (not index.html) and
> Gruntfile.js (to include it in compilation and testing)*
>     - when new external library added, add its mapping as
> libdir.amd.json (not into index.html; libdir being name of directory
> when lib was installed), add it to deploy.js or devel.js (where it
> belongs), and rerun 'grunt devel' (to regenerate config.js and the.js).
>
>   - When developing a library, not an app, there is no need to have two
> sets and deploy / devel modes, as one is _always_ in devel mode with
> library (only app then includes it then minifies it into the app
> all-in-one file). So the above things may be simplifies by having just
> one load set.
>   - Also, when developing library, it is crucial to select good
> namespace to be present in local.amd.json, as client of the library will
> automatically get mappings in library's local.amd.json integrated in
> their apps.
>
> * I know there's two space problem here. Hopefully future brings a
> solution where there will only be one list, not three.
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Free forum by Nabble Edit this page