Spring cleaning: changes to require and self in the SDK
42 views
Skip to first unread message
Jeff Griffiths
May 7, 2012, 7:01:07 PM5/7/12
to mozilla-la...@googlegroups.com
Irakli recently posted a �Spring Cleaning� todo list (
https://github.com/mozilla/addon-sdk/wiki/Spring-cleaning-2012 ) of
changes we are proposing to make to the SDK in the next few months.
While most of these changes deal with how the SDK is implemented and
will not affect the behaviour of the top-level APIs, there are two
specific changes that will change how the SDK behaves in specific
circumstances.
Changes to require()
In the first case, the behaviour of the SDK�s require statement will be
greatly simplified to support 3 explicit use cases: loading local
modules via relative paths, loading module names from the SDK�s high
level APIs, or loading via a dependency�s explicit path. Not only does
this greatly simplify the implementation of the module loader, it will
also allow us to make 3rd party module development and sharing much
simpler. A nice side effect is that require will work exactly how it
does in node.js.
The proposal clarifies the three styles to be used when requiring a module:
1. Relative path for modules included in the add-on�s lib directory
require('./utils/something')
require('../foo/bar')
2. Single term for high level SDK dependencies:
require('panel')
require('tabs')
3. Complete require form for external dependencies:
require('api-utils/functional')
require('io/fs')
require('package-name/module/path')
Once this change is made, require will raise warning for any deprecated
require usage. Eventually support for older usage patterns for require
will be removed.
Why are we doing this? The main goal is to remove ambiguity in how the
argument you supply to require is resolved. Currently these patterns are
supported, but will be deprecated:
require('functional')
require('fs')
require('module/path')
In particular, the first example ( require('functional') ) currently
means too many things:
require('addon-kit/functional')
require('api-utils/functional')
require('./functional')
require('io/functional')
require('package-name/functional')
Changing to this more explicit require form makes us more compatible
with other commonjs platforms like nodejs and also makes it distinction
between high and low level APIs more obvious. While we will make our
best efforts to keep high level APIs (ones that do not have `/` in
require: require(�panel�) ) backwards compatible at all times, we may
change low level APIs when it makes sense.
Changes to self.data
In the second case, we will be changing how the SDK�s self module
resolves the location of the data directory, specifically in the case
where a statement like self.data.load is called from inside a package
that is loaded in as a dependency in an add-on.
With the current implementation this code would try to load files from
the package�s own data directory. In the proposed change we would
instead load files from the add-ons main data directory.
Now, as far as we can tell this use of files in a package�s data
directory is not a wide-spread practice, in fact Irakli could not find a
single module on Builder that uses this behaviour. This is a breaking
change to the SDK�s apis, however, but we think this particular use case
is obscure.
As always, we�d love to hear your feedback on these changes and how they
might affect you. We want to make sure we have your input before making
changes such as these, and to ensure as much as possible that we do not
break your add-ons as we improve the SDK.
https://github.com/mozilla/addon-sdk/wiki/Spring-cleaning-2012 ) of
changes we are proposing to make to the SDK in the next few months.
While most of these changes deal with how the SDK is implemented and
will not affect the behaviour of the top-level APIs, there are two
specific changes that will change how the SDK behaves in specific
circumstances.
Changes to require()
In the first case, the behaviour of the SDK�s require statement will be
greatly simplified to support 3 explicit use cases: loading local
modules via relative paths, loading module names from the SDK�s high
level APIs, or loading via a dependency�s explicit path. Not only does
this greatly simplify the implementation of the module loader, it will
also allow us to make 3rd party module development and sharing much
simpler. A nice side effect is that require will work exactly how it
does in node.js.
The proposal clarifies the three styles to be used when requiring a module:
1. Relative path for modules included in the add-on�s lib directory
require('./utils/something')
require('../foo/bar')
2. Single term for high level SDK dependencies:
require('panel')
require('tabs')
3. Complete require form for external dependencies:
require('api-utils/functional')
require('io/fs')
require('package-name/module/path')
Once this change is made, require will raise warning for any deprecated
require usage. Eventually support for older usage patterns for require
will be removed.
Why are we doing this? The main goal is to remove ambiguity in how the
argument you supply to require is resolved. Currently these patterns are
supported, but will be deprecated:
require('functional')
require('fs')
require('module/path')
In particular, the first example ( require('functional') ) currently
means too many things:
require('addon-kit/functional')
require('api-utils/functional')
require('./functional')
require('io/functional')
require('package-name/functional')
Changing to this more explicit require form makes us more compatible
with other commonjs platforms like nodejs and also makes it distinction
between high and low level APIs more obvious. While we will make our
best efforts to keep high level APIs (ones that do not have `/` in
require: require(�panel�) ) backwards compatible at all times, we may
change low level APIs when it makes sense.
Changes to self.data
In the second case, we will be changing how the SDK�s self module
resolves the location of the data directory, specifically in the case
where a statement like self.data.load is called from inside a package
that is loaded in as a dependency in an add-on.
With the current implementation this code would try to load files from
the package�s own data directory. In the proposed change we would
instead load files from the add-ons main data directory.
Now, as far as we can tell this use of files in a package�s data
directory is not a wide-spread practice, in fact Irakli could not find a
single module on Builder that uses this behaviour. This is a breaking
change to the SDK�s apis, however, but we think this particular use case
is obscure.
As always, we�d love to hear your feedback on these changes and how they
might affect you. We want to make sure we have your input before making
changes such as these, and to ensure as much as possible that we do not
break your add-ons as we improve the SDK.
Soufian Jaouani
May 10, 2012, 7:12:19 AM5/10/12
to mozilla-la...@googlegroups.com
Regarding self.data and the data folder. Currently in the root of an add-on, before packaging, you can include scripts, html files, css files in the ./data folder.
What is going to happen to that folder?
What is going to happen to that folder?
Irakli Gozalishvili
May 10, 2012, 10:47:42 AM5/10/12
to mozilla-la...@googlegroups.com
Hi Soufian,
There is absolutely no changes to how self.data will work in regard to ./data folder placed in the root of your add-on, it only affects external packages / third party libraries that use self. I wrote a small example explaining the difference in behavior:
Please let me know if you need further clarifications
--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mozilla-labs-jetpack/-/R6BZL7rHyxQJ.
To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
Irakli Gozalishvili
May 15, 2012, 4:03:25 PM5/15/12
to mozilla-la...@googlegroups.com
Described changes to the `self` module have landed to master
Reply all
Reply to author
Forward
0 new messages