-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Conversation
|
Done. I just noticed that Also, are these functions used by any extensions? I can't check (don't have the catalog on my computer). If not, we can outright move these too. |
@le717 They're very coupled to Live Preview, so I'd like to keep them located there if possible. The module 'LiveDevelopment/main.js' is a common module between the two impls, but since it depends on them already we'd create a cycle by putting common code there and having the impls depend back on it. There's a tremendous amount of duplicated code between the two impls, so I assume we'll eventually want a common place to put code they both share (unless we're sure the old impl will entirely go away soon, but I don't see a clear path for that yet). Maybe starting a new module like LiveDevelopmentUtils or LiveDevelopmentCore would be worth it.
|
While there is indeed a lot of duplicated code, I do not feel comfortable attempting to consolidate that. Already I can see small functions that, if moved, would change their arguments in a way that is probably not wanted. What about making a LiveDevelopmentUtils with those two functions for now and let the multibrowser devs later on clean up and consolidate the duplicated code? |
Yep, that's what I was proposing. |
All done, commits flatten too. Ready for final review. :) |
@@ -885,5 +885,45 @@ define(function (require, exports, module) { | |||
expect(LanguageManager.getLanguageForPath("test.abcxyz").isBinary()).toBeFalsy(); | |||
}); | |||
}); | |||
|
|||
describe("getCompoundFileExtension", function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you still need to remove the original copy of this from FileUtils-test.
One last cleanup idea, if you want to add it in: move |
@le717 Thanks for this! Just a few small changes and then I think it's good to go. |
But wouldn't this create a circular dependency, as Bracket's impl uses Otherwise, review changes pushed. |
Move showFileOpenError() to DCH Update internal calls to getCompoundFileExtension() Relocate isCSSPreprocessorFile() Remove isCSSPreprocessorFile() redirect Update tests Introduce new LiveDevelopmentUtils module Redirect/remove _isStatic/ServerHtmlFileExt() Make _isStatic/ServerHtmlFileExt() use language id
I was right. Just performed those changes and Brackets locked up, with AppshellFileSystem throwing an "FileUtils is not defined" error, which means a circular dependency has been created (I've seen this error a lot throughout making this PR). Yet again, maybe another issue to file so a good fix can be discussed and put in place? Ready for merging. |
Ugh, that's a mess -- nothing in the filesystem package was supposed to have any dependencies on the rest of Brackets, originally. Scratch that change then -- leaving the const in FileUtils isn't so bad, and forks with a different fs impl can just change the constant there instead (they will have plenty of other diffs against master anyway). |
Alright, looks great! Seems stable, tests pass -- thanks for cleaning this up! |
Deprecate some circular dependencies with FileUtils so they can be removed later
/*global define */ | ||
|
||
/** | ||
* Set of utilities for working with files and text content. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realized this module summary is completely wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, good catch -- feel free to put up a small PR with a fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do.
I guess I should have titled this PR better, as this does not actually remove any circular dependencies. Rather, it moves some things around so the cycles can be removed. How long do you think the warnings should stay in place? I know extensions need to be updated, but since removing the deprecated things and fixing the |
We usually leave deprecations for longer than that. It doesn't seem urgent to remove the shims since the existing async-loading workarounds work just fine, and the messy workaround code is very self-contained (i.e. the quality/maintainability impact is quite limited). |
Ah, OK. My issue are there is no real guidelines as to when shims/deprecated items should be released. Obviously it will depend on the amount the APIs are used in extensions, but I'd still think there is an estimated/ideal time span before complete removal. |
There's no specific standard timeframe, but I can't think of any case where we removed an API the very next release after it was deprecated. I'd say we usually wait a couple releases, then re-check how many current extensions are still using the APIs (if any) and make a decision from there. |
* commit 'e56192e09ceed72834985f2483ed70e339e5c519': Logos are now perfectly centered Whitespace trimming suggested by @marcelgerber Fix some moved APIs that were left over from PR adobe#10641 Text is now perfectly centered
(Branched off discussion in #10600)
isCSSPreprocessorFile()
-> CSSUtils_isStatic/ServerHtmlFileExt()
-> LiveDevelopmentgetSmartFileExtension()
-> LanguageManager, and maybe rename to something likegetCompoundFileExtension()
for clarityshowFileOpenError()
to DocumentCommandHandlers, next to_showSaveFileError()
To note, moving
showFileOpenError()
to DCH and_isStaticHtmlFileExt()
to LiveDevelopmentUtils are creating a circular dependencies (sigh) during deprecation.Once merged, I suggest these APIs are put on the fast track for removal so the cycles they will resolve (and temporarily create/prolong) are removed.
/cc @peterflynn