Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set up scaffolding in master branch for conversion to dojo-core and TypeScript #130

Closed
kfranqueiro opened this issue Jun 24, 2015 · 0 comments
Assignees

Comments

@kfranqueiro
Copy link
Contributor

As you may know, Dojo 2 is currently in development, and is being written in TypeScript. The goal is to use dstore as its store API, but is currently written in JavaScript using Dojo 1.

In order to integrate more seamlessly into the overall Dojo 2 platform, our goal is to convert it to TypeScript and rely on Dojo 2's core instead of Dojo 1. The first step in that process is to reorganize the repository to incorporate most of the aspects of the Dojo 2 Package Template.

Update: This is now merged. Below are some general goals and guidelines for the subsequent conversion process.

Converting dstore to TypeScript

The master branch of dstore has been restructured to facilitate conversion to TypeScript. The 1.x branch now serves as a placeholder for any future 1.x releases, though currently we are only planning to focus on the TypeScript conversion for 2.0, and any necessary bugfixes to 1.0.x and 1.1.x.

Goal

The initial focus of the TypeScript conversion should be on a pure, direct conversion as much as possible. We will undoubtedly come up with pain points and implementation feedback, and while it is important to take note of these, the initial conversion should not be permitted to diverge into arbitrary refactoring beyond what is necessary for proper typing (that will come on a subsequent pass).

There are two motivations behind this:

  • To keep the initial changesets straightforward - git is unlikely to recognize these conversions as renames and preserve history, so it is imperative that the files remain as close to their 1.x counterparts as possible and changes don't sneak in under the radar
  • To prevent conversion tasks from derailing and bloating

We will most likely be organizing this effort per-module and will enter GitHub issues to match. If pain points / feedback are encountered, they should be noted via comments on the respective issue, so that we can collect them later to form a more complete picture and decide what needs to change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant