proposal

[zwetan]

1. Rename the project from SWFObject to SWFObject3
   reasons:
   • too many CDN, repositories, package managers, etc. use the name swfobject
     see for example swfobject on npmjs
   • it's not like the original authors of the project officially transferred the project to us
     we just took over an abandoned project
   • changing name could avoid confusion
   • but technically it would work as a fork as we would preserve the licensing, copyright of original authors, etc.
2. Refactor the code and port it to TypeScript
   reasons:
   • even if the code base is small, using TS allow to export to different modules
     eg. --module with commonjs, amd, system, etc.
     by preserving a unique code base
   • using the type system and niceties of TS does not hurt ;)
   • could solve problems like the following
     pull request #12 Added UMD wrapper to make swfobject compatible with CommonJS and AMD
     or avoid patches on top of the library like this one
3. Bump the versioning to v3.0
   reasons:
   • SWFObject already has a complicated history of naming and versioning
     using something like SWFObject3 v1.0 would create confusion
   • using SWFObject3 starting at v3.0
     show a clear intent of cutting ourself off the past
     eg. "anything before v3.0 is the 'old' SWFObbject"
   • allow us to enforce a clear semantic versioning
     a major version change allow us to change the main SWFObject API if we need to
     eg. "MAJOR version when you make incompatible API changes"
4. Clear listing of the tools and stack
   reasons:
   • enforce an automated build
   • everyone involved in the project or wishing to contribute to it
     in sync to use the same tools, stack etc.
   • enforce a specific way to test (TBD)

[zwetan]

@ricovitch and @drunkcat please do comments

[ricovitch]

Very good points. I totally agree with the 3 first points. For the last point i'm not so sure, but as general principles this sounds good to me.

[zwetan]

the last point is about explaining things like "howto build" and "howto test" and "howto report problem" etc.

the "enforce a specific way to test" is more inline with if somehow SWFObject2 fail on something is to encourage to go to "some test page" to record the results so we can see which context create this specific fail and so gather info about it like the user-agent, the amount of RAM, the browser version, etc.

let's see it like that even if we were 100 dev working on this we will unlikely be able to test everything, there will always be edge case because of all the different browser environment you can have, so if we have a page to record that kind of stuff it can help

I'm thinking about what have been done with jQuery explained here JavaScript Testing Does Not Scale

and think of the browser grid as it can be seen here http://kangax.github.io/compat-table/es5/

we need to have our own specific grid of things that we can support and test, even if we are not able to test everything (at least someone can load a specific page to validate the test for us)

for ex: anything server-side like Rhino, Node.js etc would not be supported but we may need to add support for NW.js, Atom Electron, etc.

that's the general idea, I don't have everything figured out yet

[zwetan]

about tooling

• TypeScript for the main code base
  $ npm install -g typescript
  cli: tsc
• TypeDoc for the code documentation
  $ npm install -g typedoc
  cli: typedoc
• UglifyJS2 for the JS compressor/minifier
  $ npm install -g uglify-js
  cli: uglifyjs
• automated build
  based on npm run and bash (if needed)

we should end up with a package.json looking like that

{
  "name": "swfobject3",
  "version": "3.0.0",
  "private": true,
  "devDependencies": {
    "typescript": "~1.8.7",
    "typedoc": "~0.4.0",
    "uglify-js": "~2.6.2"
  },
  "scripts": {
    "build-js": "tsc src/swfobject3.ts",
    "build-doc": "typedoc src/swfobject3.ts",
    "build": "npm run build-js && npm run build-doc",
    "compress": "uglifyjs swfobject3.js -o swfobject3.min.js",
    "deploy": "npm run build && npm run compress"
  }
}

[zwetan]

We will need also to build Flash stuff like expressInstall and for that we will probably require a Flex SDK install and rely on either bash (to be minimalist) or ant (to reuse flextask.jar)

but we will look at that in a 2nd phase, let's first focus on JS